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I.  HARMONIZED  CONSTRAINTS  IN  SOFTWARE 
ENGINEERING  AND  ACQUISITION  PROCESS  MANAGEMENT: 
REQUIREMENTS  ARE  THE  KEY  TO  SUCCESSFULLY  MEET 
FUTURE  PERFORMANCE  GOALS  IN  AN  ENVIRONMENT  OF 

SCARCE  RESOURCES 


A.  INTRODUCTION 

The  acquisition  community,  Congress,  companies,  and  taxpayers  consider  the 
Department  of  Defense  (DoD)  acquisition  process  to  be  a  broken  system.  They  are  weary 
of  endless  program  failures,  cost  overruns  and  delayed  schedules  for  major  acquisition 
programs.  However,  this  is  the  only  commonality  of  their  judgements.  Stakeholders  do 
not  enjoy  being  reminded  of  their  own  contribution  to  the  mess  and  are  more  than  willing 
to  pass  the  blame  to  anyone  else.  They  all  have  different  opinions  of  what  is  wrong  with 
the  sophisticated  system,  which  appears  to  be  sensible  when  considering  the  process 
alone.  Budgets  will  remain  tight  in  the  future  because  there  are  many  other  challenges, 
apart  from  the  defense  budget,  appearing  at  the  horizon.  Everyone  agrees  that  the  system 
needs  to  be  fixed  quickly  because  of  the  scarce  resources  apparent  in  future  budgets. 
Gathering  a  sufficient  piece  of  the  budget  is  essential  to  providing  high  quality  weapons 
systems  to  the  warfighters  that  are  desperately  needed  to  face  upcoming  threats  and 
challenges. 

Modernization  and  unexpected  developments  must  be  addressed  as  well. 
Considering  the  tight  budget  constraints,  this  is  a  difficult  task.  The  need  for  a  solid,  fast 
and  reliable  solution  to  this  inappropriate  situation  is  urgent,  and  requires  extensive 
analysis.  The  goal  is  to  find  the  roots  of  the  various  problems  in  order  to  make  the  system 
work.  Two  of  the  most  critical  causes  of  acquisition  problems  are  the  development  of 
sufficient  system  and  software  requirements.  To  understand  this  relationship,  the  facets  of 
this  complex  and  complicated  system  must  be  examined:  important  stakeholders, 
influential  factors,  and  the  challenges  and  opportunities  ahead.  Goals  of  the  Project  are 
illustrating  common  problem  areas,  developing  new  insights,  addressing  future  needs, 
and  offering  recommendations  for  addressing  some  of  the  current  weaknesses. 
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B. 


COMMONALITIES  AND  DIFFERENCES 


To  understand  the  role  of  software  development  and  general  requirements  within 
the  acquisition  process,  the  commonalities  and  differences  of  these  two  segments  will  be 
examined. 

1.  Commonalities 

Software  and  general  requirements  are  derived  from  the  same  source:  the  goal1  of 
closing  a  capability  gap.  The  functional  analysis,  which  is  driven  by  the  operational 
requirements  needed  to  achieve  this  goal,  leads  to  both  preliminary  and  detailed  design 
attributes. 

2.  Differences 

The  functional  analysis  step  is  where  the  two  kinds  of  requirements  deviate. 
General  requirements  investigate  the  design  attributes  needed  for  the  physical 
characteristics  of  the  new  system.  Software  requirements  identify  the  attributes  and 
important  functions  that  will  be  perfonned  by  software  in  the  new  system,  not  by 
hardware  of  the  preliminary  design2.  Both  address  the  interfaces,  testing,  and 
integration3  necessary  for  the  new  system  to  work  smoothly  and  reliably  using  different 
means.  All  these  efforts  take  place  during  the  design  phases  before  the  actual  production 
process.  What  is  evident  from  this  is  that  the  requirements  must  be  generated  in  a 
completely  different  environment  within  the  acquisition  process.  The  further 
development  of  these  requirements,  beginning  with  the  functional  analysis,  is  completely 
different  and  often  misunderstood. 


1  See  also  Systems  Engineering  And  Analysis,  Fourth  edition,  Blanchard/Fabrycky,  p.  99,  Figure  4.3. 

2  See  also  Systems  Engineering  And  Analysis,  Fourth  edition,  Blanchard/Fabrycky,  p.  100,  Figure  4.4. 

3  See  also  Systems  Engineering  And  Analysis,  Fourth  edition,  Blanchard/Fabrycky,  p.  100,  Figure  4.4. 
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c. 


METHODOLOGIES  AND  MODELS 


This  research  uses  various  analytical  techniques  referring  to  case  studies  and 
models  to  illustrate  the  roots  of  problems  within  the  acquisition  process.  It  also  uses 
models,  data  and  case  studies  to  support  the  recommendations  and  conclusions. 

D.  SHORTFALLS  IN  THE  INFLUENTIAL  FACTORS  AND  THEIR  IMPACT 
ON  THE  SUCCESS  OF  A  MAJOR  ACQUISITION  PROGRAM 


First,  it  is  necessary  to  present  the  most  common  and  important  sources  that  lead 
to  the  frequently  experienced  shortcomings  of  cost  and  schedule  overruns.  The  research 
investigates  their  general  impact  on  major  acquisition  programs  and  focuses  on  six  major 
sources  for  each  segment.  These  sources  are  not  exhaustive  but  address  the  most 
influential  areas  of  the  current  weaknesses  experienced  within  the  different  processes. 

1.  Shortfalls  in  the  Software  Segment  and  Their  Impact 


Figure  1.  Major  shortfall  areas  in  software  development 


a.  Lack  of  Understanding  Software  Requirements 

At  the  beginning  of  the  acquisition  process,  detailed  software  requirements 
of  the  new  system  are  always  unknown  because  the  overall  amount  of  software  required 
is  determined  by  the  functional  needs  that  are  elaborated  early  in  the  acquisition  process. 
It  is  essential  that  the  user  requirements  be  correctly  translated  into  software  requirements 
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that  address  the  system  attributes  derived  from  the  functional  architecture.  It  is 
particularly  important  to  accurately  estimate  the  amount  of  software  development  needed 
with  as  much  realism  as  possible. 

Another  crucial  factor  is  the  software  design,  which  will  mirror  only  the 
functional  requirements  that  are  articulated  in  the  requirement  analysis.  These 
requirements  shape  the  framework  and  capabilities  of  the  software  designed.  This 
relationship  has  a  critical  impact  on  even  the  smallest  change  that  has  to  be  made  after 
this  early  stage  of  development,  and  is  one  of  the  most  powerful  factors  of  cost  and 
schedule.  Overly  optimistic  assumptions  of  the  total  amount  of  software  needed  leads  to 
initial  delays,  as  demonstrated  by  various  programs  such  as  the  F224,  FCS5  and  SBIRS6 
programs. 

Software  developers  use  a  similar  checklist7  for  developing  hardware.  It 
prepares  for  design  reviews  of  the  system  to  verify  their  compatibility  and  testability.  The 
software  development  environment  is  not  mature  enough  to  allow  for  common 
development  practices  and  compared  to  the  hardware  sector,  has  few  verified  and  suitable 
tools.  However,  there  has  been  significant  progress  since  the  early  days  of  software 
development.  Modem  software  languages  allow  more  flexibility,  focus  on  functional 
needs  instead  of  lines  of  code,  and  increasingly  support  an  open  architecture  that  is 
advantageous  for  maintainability  and  sustainability  of  embedded  software  in  major 
weapon  systems8. 


4  F22  Raptor,  first  supersonic  stealth  fighter  of  the  USAF. 

5  FCS,  Future  Combat  System  of  the  U.S.  Army. 

6  SBIRS,  Space  Based  Infrared  System. 

7  A  typical  checklist  for  this  purpose  is  illustrated  as  an  example  in  Systems  Engineering  And 
Analysis,  Fourth  edition,  Blanchard/Fabrycky,  page  730,  Figure  B.2. 

8  See  also  Joint  Strike  Fighter  Air  Vehicle  C++  Coding  Standards  For  The  System  Development  and 
Demonstration  Program,  December  2005  at 

http://www.isf.mil/downloads/documents/JSF  AY  C%2B%2B  Coding  Standards  Rev  C.doc  Last 

accessed  February  2008. 
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b.  Lack  of  System  Thinking 

The  expression  Tack  of  system  thinking’  refers  to  two  different  major 
aspects:  we  try  to  make  sense  of  reality  applying  filters  and  making  assumptions.  This  is 
a  helpful  and  vital  tool  for  dealing  with  every-day  life.  However,  these  experience-based 
assumptions  incorporate  delays,  biases,  errors  and  other  imperfections.  It  is  necessary  to 
be  aware  of  this.  To  avoid  those  inherent  mistakes,  a  vast  amount  of  feedback 
possibilities  must  be  implemented.  Even  then,  there  will  be  misperceptions  of  the 
feedback9.  Unfortunately,  false  assumptions  occur  often  when  they  rely  on  limited 
experience  alone. 

As  researched  by  Scott  Pious10  in  1993,  overconfidence  is  a  common  and 
catastrophic  problem  in  decision  making.  His  research  indicates  that  judgements  are 
rarely  accurate.  To  gain  confidence,  assumptions  must  be  corroborated  by  as  much  data 
as  possible.  However,  data  bases  alone  are  not  sufficient  to  avoid  errors  completely 
because  they  are  limited  and  often  allow  ambiguous  interpretations.  Desire  for  change 
within  a  system  might  not  become  true  simply  because  it  cannot  replicate  the  full 
dynamic  complexity11  of  the  system.  This  fact  is  a  limiting  factor  to  the  success  of  any 
conclusions  and  recommendations  made  in  this  report.  Nevertheless,  if  consequences  are 
thoroughly  investigated,  the  recommendations  will  be  of  some  use  to  improve  the 
existing  difficulties  if  they  are  carefully  applied. 


9  See  also  Business  Dynamics,  Systems  Thinking  and  Modeling  for  a  Complex  World,  Sterman  John 
D.,  p.  27,  Table  1-4  that  shows  numerous  studies  that  have  documented  this  observation. 

10  See  also  Business  Dynamics,  Systems  Thinking  and  Modeling  for  a  Complex  World,  Sterman  John 
D.,  p.  272,  Overcoming  Overconfidence. 

11  See  also  Business  Dynamics,  Systems  Thinking  and  Modeling  for  a  Complex  World,  Sterman  John 
D.,  p.  22,  Table  1-3  that  illustrates  our  difficulties  to  understand  a  system  as  a  whole  entity. 
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c.  Lack  of  System  Engineering  Principles 

As  demonstrated  in  various  acquisition  programs12,  system  engineering 
principles  and  models13  are  key  tools  for  successfully  developing  a  system.  These 
principles  however,  need  to  be  applied  continuously,  require  strict  oversight  and  good 
communication  among  the  different  stakeholders,  and  a  chief  system  engineer  who  is 
experienced  in  the  segment  of  the  system  that  is  to  be  developed.  The  steady  and 
determined  application  of  systems  engineering  principles  and  tight  oversight  is  even  more 
essential  since  the  lack  of  software  requirements  and  system  thinking  are  common  themes 
in  failed  projects14.  One  example  of  rushing  into  CDR  and  production  is  the  SBIRS  high 
program.  According  to  a  brief  in  class  by  a  fonner  student  involved  in  the  program,  the 
program  went  into  CDR  with  immature  software  (only  about  50%)  of  the  total  amount  of 
software  produced  and  immature  technology  of  subsystems  still  a  problem  at  production 
start.  System  engineering  principles  are  crucial  in  developing  designs  that  accommodate 
current  and  future  software  and  hardware  attributes  within  a  complex  development 
environment  for  complicated  system-of-systems  architectures.  On  average,  major  weapon 
system  programs  software  development  tends  to  require  almost  twice  the  scheduled  cost, 
and  more  than  220  percent  of  what  was  estimated  at  the  start  of  the  program15.  The 
demand  for  cutting  edge  technology  in  almost  every  major  program  is  one  cause  of  this 
situation  because  of  its  associated  uncertainties  and  risks. 


12  For  example  SSGN  Trident  conversion  program,  Aircraft  F18  E/F  upgrade  program,  Link  16 
program,  Unmanned  aerial  vehicle  Predator  A  MQ-1  /  B  MQ-9  program. 

13  See  also  Systems  Engineering  And  Analysis,  Fourth  edition,  Blanchard/Fabrycky,  p.  131,  Figure 
5.6. 

14  See  also  Developing  Software  Requirements  Supporting  Open  Architecture  Performance  Goals  in 
Critical  DoD  System-of-Systems,  Naegle  Brad,  p.  10. 

15  See  also  General  Accounting  Office,  Defense  Acquisitions:  Stronger  management  practices  are 
needed  to  provide  DoD’s  software-intensive  weapon  acquisitions,  Report  to  Committee  on  Armed  Service, 
U.S.  Senate,  March  2004,  publication  no.  GAO-04-393,7. 
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d.  Management  Issues 


Management  issues  in  the  software  development  segment  are  often  related 
to  underestimations  of  the  amount  of  work  needed  to  accomplish  the  tasks.  It  is  better  to 
start  with  too  many  programmers  and  reduce  the  numbers  later  on  because  adding 
personnel  late  in  the  process  is  usually  detrimental  as  different  publications  on  this 
specific  topic  16  show. 


e.  People  Issues 

Software  development  for  complex  weapon  systems  is  different  from 
software  development  for  commercial  businesses.  The  main  defense  contractors  have 
typically  employed  people  from  one  pool  of  programmers  for  their  projects.  This  has  two 
advantages:  they  are  already  familiar  with  the  special  demands  of  the  Department  of 
Defense  environment  and  are  also  aware  of  special  regulations  and  rules  of  the  prime 
contractor.  This  means  they  can  be  easily  integrated  into  the  working  environment.  Other 
contractors  discovered  this  phenomenon  and  have  struggled  with  basic  applications  due 
to  the  lack  of  qualified  software  developers  due  to  the  competition  for  the  same  developer 
pool17. 


f.  External  Forces 

Software  development  is  a  sensitive  area,  but  crucial  for  the  smooth 
functional  performance  and  integration  effort18  of  subsystems  and  their  components. 
Disruptions  in  software  development,  like  adding  new  requirements  late  in  the 


111  See  also  The  Dynamics  of  Software  Project  Staffing:  A  System  Dynamics  Based  Simulation 
Approach,  Abdel.Hamid  Tarek  K.,  IEEE  TRANSACTIONS  ON  SOFTWARE  ENGINEERING,  Vol.  15, 
No. 2,  February  1989  and  The  Experience  Trap,  Sengupta/Abdel-FIamid/Van  Wassenhove,  Flarvard 
Business  Review,  February  2008. 

17  As  for  example  Northrop  Grumman  Ocean  Systems  had  to  learn  when  they  allowed  a  subcontractor 
use  an  old  software  application  to  develop  the  Advanced  Seal  Delivery  System,  ASDS,  a  program  that  was 
cancelled  due  to  multiple  shortcomings  later  on. 

18  See  also  Systems  Engineering  And  Analysis,  Fourth  edition,  Blanchard/Fabrycky,  p.  106,  Figure 
4.7. 
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development  process,  or  software  immaturity  due  to  poorly  defined  requirements,  will 
lead  to  major  delays  in  schedule  and  massive  cost  overruns19. 

External  forces  are  a  permanent  and  serious  challenge  to  the  software 
development  segment  of  acquisition  programs.  A  lack  of  understanding  of  relationships 
within  the  process,  requirement  additions,  funding  changes,  schedule  pressures,  and 
interference  from  political  interest  groups  can  have  a  very  negative  impact  on  acquisition 
programs,  even  if  solid  system  engineering  and  acquisition  management  processes  are  in 
place.  A  major  concern  in  the  software  development  sector  is  a  poor  understanding  of  the 
processes  that  differ  from  the  rest  of  the  system’s  development.  As  an  example, 
successful  software  development  depends  heavily  on  small  incremental  steps  and  a  high 
demand  for  testing.  This  causes  significant  confusion  and  is  often  misunderstood20. 
Software  is  different  in  contrast  to  developing  a  new,  cutting-edge  hardware  component 
or  technology;  non-software  development  is  typically  not  the  problem.  Software  depends 
basically  on  lines  of  code  that  are  necessary  to  achieve  the  desired  function,  but  systems 
are  complex.  It  is  rare  that  a  complex  system  works  as  desired  when  first  developed,  and 
requires  significant  testing  to  ensure  reliability  and  safety  aspects  expected  from  weapon 
systems.  This  also  applies  for  programs  that  are  costly  and  do  not  have  any  failure 
tolerance  at  all21.  Political  stakeholders  are  sometimes  not  aware  of  the  additional  risks22 
they  impose  with  changes  in  schedule,  funding,  and  requirements,  or  the  related  impact 
on  the  warfighters  and  the  taxpayers  in  the  long  run. 


19  A  good  example  is  the  SBIRS  program  that  had  to  take  94  requirement  changes  after  preliminary 
design  and  went  into  detailed  design  with  less  than  50  of  the  software  accomplished. 

20  See  also  Developing  Software  Requirements  Supporting  Open  Architecture  Performance  Goals  in 
Critical  DoD  System-of-Systems,  Naegle  Brad,  pp.  11,  18. 

21  Good  examples  for  such  systems  are  satellite  systems,  space  programs  like  the  Space  shuttle 
because  any  failure  might  result  in  complete  loss  of  the  mission  or  system. 

22  See  also  Systems  Engineering  And  Analysis,  Fourth  edition,  Blanchard/Fabrycky,  p.  711,  Figure 
19.12. 
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2.  Shortfalls  in  the  Acquisition  Process  and  Management  Segment  and 
Their  Impact 

Figure  2.  Major  shortfalls  areas  in  the  acquisition  process 


a.  Organizational  and  DoD  Specific  Structural  Problems 

In  this  section,  typical  problems  within  the  acquisition  processes  and 
acquisition  environment  are  explored  in  more  detail.  The  factors  here  are  more  numerous, 
but  can  have  the  same  devastating  effects  on  programs  as  those  imposed  during  software 
development. 

The  structural  and  organizational  framework  of  the  DoD  environment 
provides  ample  opportunity  to  implement  changes,  improve  efficiencies,  clarify 
responsibilities,  and  balance  supervision  and  control.  However,  change  is  difficult  to 
implement,  especially  in  such  a  large  and  interdependent  structural  framework  like  the 
Department  of  Defense23.  Therefore,  any  change  will  always  face  considerable  resistance 
and  require  significant  time  before  it  is  fully  implemented  and  embraced. 

The  obligation  to  reduce  personnel  costs  in  the  DoD  environment  has 
deteriorated  the  acquisition  experience  base  as  well  as  knowledge  redundancy. 
Unfortunately,  the  loss  of  knowledge  was  far  greater  than  the  reduction  of  the 
workforce24.  Two  areas  that  were  crippled  by  this  effect  were  the  general  acquisition 

23  See  Organizational  Behavior,  Me  Shane/von  Glinow,  Me  Graw-Hill/Irwin,  New  York  2007,  chapter 
14. 

24  As  stated  during  MN3304  class,  Yoder  Cory. 
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workforce,  and  within  this  community,  the  contracting  specialists.  Experienced  personnel 
were  required  or  given  incentive  to  leave;  the  professionals  remaining  had  to  deal  with  a 
large  and  increasing  number  of  programs.  Time  is  precious  and  there  are  not  enough 
employees  to  properly  analyze  the  programs  in  great  detail.  This  leads  to  an  increased 
danger  of  ‘playing  the  system’  and  causing  damage  to  the  trust  of  the  regulations  in 
place25. 

In  addition,  frequent  cost  and  schedule  overruns  of  many  programs  did  not 
result  in  a  deeper  investigation  of  their  causes.  Rather,  it  resulted  in  rapidly  evolving  new 
regulations  and  supplements  to  the  Federal  Acquisition  Regulation  (FAR)  and  other 
directives.  For  those  trying  to  operate  within  the  acquisition  processes,  this  made  work 
even  harder.  The  regulatory  additions  addressed  the  symptoms  of  the  problems  instead  of 
the  cause.  The  envisioned  workload  reduction  after  the  Cold  War  era  was  supposed  to 
allow  smaller  Services  and  a  reduced  civilian  workforce  through  a  decline  in  transactions 
and  smaller  programs.  Fess  need  for  oversight  was  also  expected,  but  neither  ever 
became  reality.  The  increased  number  of  regulations  and  the  reduced  number  of 
surviving  contractors  capable  of  delivering  the  major  weapon  systems  made  more 
oversight  mandatory.  A  flood  of  new  regulations  attempted  to  address  the  problem  that  an 
inexperienced  workforce  faced  as  schedule  pressures  and  work  overload  increased,  which 
triggered  more  compliance  effort,  that  led  to  even  more  cost  and  schedule  overruns. 

Program  Managers  (PMs)  willingly  contribute,  more  or  less,  to  the 
problems.  Because  their  role  is  to  successfully  complete  the  program,  they  have  no 
interest  in  revealing  its  actual  performance,  especially  if  that  perfonnance  is  not  viewed 
favorably.  Because  they  want  to  keep  their  program  alive,  they  feel  pressure  from  their 
service  to  bring  their  program  to  deployment  so  that  the  new  system  is  not  lost.  However, 
the  PMs  cannot  be  primarily  blamed  for  this  effect;  their  behaviour  is  consistently 
rewarded  and  enforced.  Even  if  this  was  not  the  case,  the  necessary  and  accurate 
information  about  real  estimated  costs  of  a  program  and  its  life  cycle  would  be  hard  for 
them  to  accurately  estimate.  This  is  because  the  contractor  is  disincentivized  in  admitting 

25  See  also  Developing  Software  Requirements  Supporting  Open  Architecture  Performance  Goals  in 
Critical  DoD  System-of-Systems,  Naegle  Brad,  p.  13. 
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the  difficulties  of  accomplishing  the  program  within  the  cost  and  timeframe.  He  will  wait 
at  least  until  production  until  he  comes  up  with  the  full  truth  and  more  or  less  reliable 
cost  of  the  program  because  before  production  he  barely  makes  any  money  at  all  on  state 
of  the  art  weapon  systems.  He  fears  that  otherwise,  the  program  will  be  reduced 
considerably  or  even  be  terminated.  This  fear  is  understandable.  An  example  using 
immature  technology  even  in  the  production  process  was  the  Advanced  Seal  Delivery 
System  associated  with  the  SSGN  conversion  program.  Immature  technology  for 
subsystems  like  the  batteries  led  to  a  lot  of  delays,  cost  overruns  and  even  more 
concerning  to  a  fatal  accident  during  testing.  This  fact  caused  a  cancellation  of  the  ASDS 
program  and  reduced  the  capabilities  of  the  converted  submarines. 

The  Services  themselves  are  major  sources  of  initial  misinformation  that 
feed  this  system.  Quantities  needed  are  exaggerated  in  expectation  that  these  numbers 
will  be  cut  by  politicians  or  budget  constraints.  Contractors  estimate  cost  and  profit  based 
on  these  numbers  and  are  quick  to  rapidly  accelerate  unit  costs  as  planned  quantities  are 
reduced  by  the  Government.  Members  of  Congress  do  not  use  the  correct  tools  to 
tenninate  these  unhealthy  relationships.  They  cut  funding  and  influence  major  programs 
for  regional  and  political  reasons.  This  behaviour  and  bias  in  favour  of  regional  revenues 
and  influence  adds  another  level  of  inefficiency  to  the  existing  problems  of  the 
acquisition  process. 

Accountability  for  results  is  low  among  the  services  and  PMs  because 
turnover  rates  are  high  and  people  change  positions  every  few  years.  Most  of  the  time, 
they  do  not  manage  a  program  for  even  one  complete  phase  of  development. 
Accountability  is  even  lower  among  politicians  influencing  the  decisions  and  contractors 
taking  advantage  of  this  reality  because  it  is  hard  to  relate  actions  taken  to  the  overall 
outcome  of  inadequate  actions,  and  influence  is  hard  to  prove.  The  Joint  Capabilities 
Integration  and  Development  System26  (JCIDS)  introduced  yet  another  source  of 
inefficiency  to  the  acquisition  process.  The  goal  was  to  achieve  more  ‘jointness’  to  all 
programs,  reduce  redundancy  among  the  services,  and  foster  interoperability  within  the 

26  For  a  detailed  historical  background  and  discussion  of  the  JCIDS  process  see  U.S.  military  Program 
Management,  Garret,  Gregory  A.  /  Rendon,  Rene  G.,  Chapter  2. 
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forces.  JCIDS  is  a  top  down  process,  but  the  expertise  that  is  really  needed  is  strongly 
related  to  the  experience  of  Combatant  Commanders,  who  are  not  well  versed  in  the 
JCIDS  or  acquisition  processes. 

Other  important  factors  are  organizational  structures  of  the  DoD  and  the 
acquisition  workforce  itself.  They  reflect  the  needs  to  handle  the  tasks  in  which  they  were 
designed.  We  can  use  organizational  structure  theories  to  investigate  aspects  of 
suitability,  function,  adaptability,  and  general  fit.  According  to  Mintzberg,27 
organizational  structure  can  be  related  to  the  structures  efficiency  in  dealing  with 
uncertainty  in  an  enviromnent  that  is  characterized  by  stability  and  complexity.  There  are 
two  ways  to  produce  undesirable  outcomes.  One  is  to  use  the  wrong  structure  for  the 
environment,  and  the  other  possibility  is  to  use  the  wrong  people  or  processes.  Both 
observations  can  be  made  by  examining  the  structures  on  different  levels  of  the  DoD 
environment  and  performing  a  stakeholder  analysis  of  all  the  key  players  in  the 
acquisition  process.  The  results  of  this  examination  will  make  clear  a  few  of  the  less 
obvious  interdependencies  and  relations  within  the  complex  structure  of  the  acquisition 
and  DoD  environment. 

b.  Legal  Restrictions 

The  amount  of  legal  restrictions28  and  regulations  is  a  barrier  to  an 
efficient  acquisition  processes.  The  rules  imposed  provide  guidance  but  current  legal 
restrictions  are  so  numerous  that  they  actually  hamper  the  flexibility  needed  in  a 
changing  acquisition  environment.  Because  there  are  so  many  laws  and  regulations,  some 
of  the  opportunities  of  the  current  legal  framework  are  not  fully  understood  or  followed 
by  the  acquisition  workforce.  A  costly  example  of  this  fact  is  the  lack  of  understanding  of 
the  implications  of  subpart  13.5  within  the  FAR  dealing  with  simplified  acquisition 
procedures  for  commercial  items  up  to  a  certain  monetary  threshold.  This  section  was 
implemented  to  reduce  transaction  costs,  ease  acquisition  processes  and  reduce 


27  Organizational  Design:  Fashion  or  Fit,  Flenry  Mintzberg,  Flarward  Business  Review  1981. 

28  A  small  excerpt  from  all  legally  binding  documents  is  presented  in  Table  3,  4  and  5. 
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acquisition  time  pressures29.  Statuaries  and  regulations  and  continuous  changes  to  the 
FAR  are  so  enonnous  that  the  acquisition  workforce  has  trouble  keeping  up  with  and 
correctly  implementing  them.  In  addition,  many  laws  and  regulations  are  designed  to 
implement  desired  societal  or  democratic  principles,  not  improve  acquisition  efficiencies. 
In  addition  to  difficulty  to  keep  up  with  the  flood  of  laws,  rules,  regulations  and 
directives  these  documents  sometimes  restrict  competition  among  the  few  global 
contractors  that  are  globally  available  to  produce  a  major  weapon  system.  This  is 
unfortunately  and  partially  contradicts  the  goals  of  the  FAR  as  the  FAR  principles  state 
that  the  amount  of  competition  should  be  maximized  whenever  possible30.  One  example 
for  legally  restricting  competition  opportunities  is  the  Buy  American  Act  that  hampers 
full  use  of  globally  available  technology  and  contractors. 

c.  Lack  of  Communication  and  Oversight 

Many  acquisition  programs  suffer  from  a  lack  of  communication  and  poor 
oversight.  The  fear  of  losing  a  program  or  admitting  to  an  unexpected  negative  event  has 
a  negative  influence  on  the  communication  of  problems  and  solutions  that  make  a 
program  successful;  errors  that  are  easily  resolved  in  their  early  stages  accumulate  until 
they  become  serious.  In  some  cases,  the  program  must  be  cancelled  due  to  this 
accumulation.  The  schedule  and  costs  needed  in  fixing  these  issues  may  become  a  major 
threat  to  the  program. 

d.  Management  and  People  Issues 

Creating  a  new  system  requires  significant  management,  coordination,  and 
communication  among  many  different  people.  This  can  become  an  issue  if  there  are 
personal  barriers  that  slow  this  process.  Involved  parties  should  be  professional  enough  to 
overcome  these  issues,  but  this  is  not  always  the  case. 


29  As  stated  during  class  MN3304,  Yoder  Cory. 

30  See  also  FAR,  subpart  1.102  Statement  of  Guiding  Principles  for  the  Federal  Acquisition  System. 
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e.  Lack  of  Understanding  and  Changing  Requirements 

A  lack  of  understanding  can  be  caused  by  poor  translation  or 
misunderstanding,  and  is  a  critical  issue  to  the  overall  success  of  a  program. 
Requirements  that  are  wrong,  unclear  or  misunderstood  can  be  fatal  to  the  success  of  a 
program.  Requirements  not  defined  clearly  and  agreed  upon  will  inevitably  lead  to 
warfighter  attributes  that  cannot  be  met  by  the  system  and  will  likely  be  considered 
inadequate.  The  relationship  is  well  characterized  by  the  following  quote:  “Why  did  we 
build  the  wrong  thing?  Because  we  could  not  get  the  requirements  right.”31  The  same 
underlying  problem  was  articulated  earlier  with  a  different  twist  by  Yogi  Berra:  “You  got 
to  be  careful  if  you  don’t  know  where  you  going,  because  you  might  not  get  there!”  This 
is  unacceptable.  Sometimes  the  missing  function  cannot  be  easily  implemented,  if  at  all, 
into  the  system  if  it  is  discovered  too  late  in  the  acquisition  process,  such  as  during  live- 
firing  and  testing.  Faults  during  the  first  steps  of  the  process  will  cause  irreversible 
problems  in  scheduling,  cost,  and  performance  in  the  new  system. 

Stakeholders  also  contribute  to  this  area  of  problems.  During  the  different 
stages  of  the  acquisition  process,  when  the  system  is  beginning  to  coalesce,  stakeholders 
add  or  change  system  requirements.  This  practice  is  as  bad  as  it  is  common.  The 
operational  requirements  were  fonnulated  according  to  the  initial  need  to  close  the 
capability  gap.  The  requirement  analysis  should  have  addressed  all  requirements  that  are 
needed  to  achieve  this  goal  Therefore,  there  should  be  no  necessity  to  add  new 
requirements  unless  specifically  driven  from  unforeseen  changes  in  the  threat  or  to  take 
advantage  of  a  truly  compelling  opportunity. 

The  real  need  for  requirement  changes  must  be  related  to  the  change  in  the 
gap  that  has  to  be  closed.  This  rarely  happens.  Most  of  the  time,  additional  or  augmented 
requirements  have  nothing  to  with  the  operational  environment  of  the  new  system.  These 
changes  entail  redundant  capabilities,  unnecessary  items,  and  irrelevant  opportunities. 
These  are  serious  threats  to  the  program  because  they  consume  development  time, 
integration  efforts,  software  development  interfaces,  testing  needs,  and  other  unplanned 


31  As  stated  during  class  MN3309,  Naegle  Brad. 
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activities.  They  reduce  the  available  budget  needed  to  fulfil  the  essential  requirements. 
The  additional  requirements  are  especially  damaging  if  the  new  system  was  designed  for 
a  specific  gap  and  the  mission  suddenly  expands  well  beyond  the  initial  requirements. 

f  External  Forces 

Changes  in  law  and  policies,  general  budget  cuts,  or  funding  for  specific 
parts  of  a  program  are  a  major  impact  on  the  success  and  efficiency  of  an  acquisition 
program.  Some  changes  are  not  predictable,  such  as  rapidly  evolving  crises  or  threats  that 
must  be  solved  by  adapting  capabilities,  missions,  and  funding. 

E.  MORE  DETAILED  DISCUSSION  OF  IMPORTANT  PROBLEM  AREAS 

This  section  analyzes  why  requirements  and  external  forces  are  of  special  interest. 
The  findings  of  this  analysis  will  identify  recurring  patterns  that  must  be  avoided  in  the 
future.  The  solutions  to  these  patterns  will  enhance  the  chances  for  successful  system 
development. 

1.  Formulation  of  Requirements 

a.  Operational  Requirements 

Formulation  of  requirements  applies  to  both  hardware  and  software 
requirements.  Both  are  generated  from  the  operational  requirements  communicated  by 
the  user.  This  area  needs  special  attention  because  every  mistake  in  elaborating, 
formulating  and  translating  those  requirements  into  functional  design  will  result  in  a 
function  that  is  not  represented  correctly  and  further  isolate  functionality  away  from  the 
user’s  need. 

Why  should  the  requirements  be  the  first  thing  to  start  with  if  it  is  so 
difficult  to  get  them  correct?  The  answer  is  simple,  but  difficult  to  accomplish  within  the 
complex  acquisition  environment  of  the  DoD:  requirements  are  the  boundaries  of  what  is 
needed,  and  also  describe  all  necessary  functions  that  must  be  accomplished.  From  this 
starting  point,  the  rest  can  be  deduced. 
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An  example  might  clarify  this  difficult  point.  Let  us  assume  there  is  an 
island  state  and  because  of  the  proximity  to  an  influential  and  powerful  neighbour  state 
this  island  feels  threatened.  The  island  state  decides  to  develop  a  “protection  system”  to 
protect  itself.  Up  to  this  point  everything  seems  to  be  logical  and  easy  to  understand, 
however,  this  is  typically  where  difficulties  begin.  The  protection  of  the  island  state 
represents  a  capability  gap  that  must  be  closed  at  the  start  of  a  major  acquisition  program. 
It  is  easy  to  go  awry  attempting  to  plan  the  ‘protection  capability’  efficiently  and 
affordably  without  unnecessary  redundancies;  there  are  many  opinions  about  the  “right” 
solution  to  this  problem.  Operational  requirements  are  useful  in  deciding  which  way  to 
proceed.  They  can  help  describe  an  optimal  solution  because  they  are  free  of  biases.  The 
requirements  focus  only  on  closing  the  capability  gap  according  to  the  operational 
parameters  of  the  state’s  special  situation.  A  parallel  process  that  is  needed  for  the 
successful  creation  of  the  new  system  has  begun.  It  faces  four  basic  challenges  at  this 
point: 

1 .  The  operational  requirements  must  be  correct.  This  requires  significant 
communication,  clarification,  and  feedback  between  the  developer,  customer,  and  the 
other  stakeholders.  Incorrect  assumptions  or  requirements  will  produce  additional  and 
unneeded  capabilities  with  negative  impact  on  cost  and  schedule,  or  even  worse,  will  not 
close  the  threat  gap  as  a  whole  and  leave  the  country  vulnerable.  This  is  anything  but 
desirable. 

2.  The  requirements  then  have  to  be  clearly  defined  and  stated.  While 
simply  stated,  this  is  can  be  incredibly  complicated  process.  There  are  likely  many 
interpretations  of  the  term  ‘protection’  that  need  to  be  explored. 

3.  All  stakeholders  involved  must  understand  the  requirements.  Precisely 
communicating  a  particular  requirement  with  high  confidence  that  the  communication 
was  well  understood  is  not  an  easy  task.  Again,  the  requirements  will  likely  be  subject  to 
interpretation  despite  all  attempts  to  clearly  communicate  them. 

4.  Requirement  changes  and  additions  must  be  kept  to  a  minimum.  All 
necessary  requirements  should  be  fully  identified,  correctly  stated,  and  implemented. 
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These  four  pitfalls  must  be  overcome  to  enter  the  next  step:  translating  the 
operational  requirements  into  functional  requirements. 

b.  Functional  Requirements 

The  purpose  of  functional  requirements  is  to  identify  functions  that  are 
needed  to  satisfy  the  operational  requirements  and  create  warfighting  capability.  In  the 
aforementioned  example,  functional  requirements  would  be  ‘protection’  against  air 
invasion,  missile  threat,  amphibious  landing  etc.,  depending  on  the  operational 
environment.  Notice  that  the  functional  needs  still  focus  on  the  need,  or  in  other  words, 
what  must  be  done,  not  how  this  particular  goal  is  achieved.  The  functional  requirement 
analysis  links  every  requirement  to  one  or  more  functions  that  must  be  met  to  satisfy  the 
need.  This  traceability  is  necessary  to  address  all  needed  requirements  and  prevent 
redundant  capabilities  that  are  already  accessible.  This  is  essential  to  develop  a  system 
that  fits  the  task  and  is  efficient  and  economically  reasonable.  The  functional  analysis 
also  investigates  the  best  approaches,  such  as  hardware,  software,  or  manpower  for 
completing  functions;  it  identifies  support  and  maintenance  needs;  and  it  gives  the  new 
system  a  rough  skeleton  consisting  of  requirements  and  structure. 

2.  Poorly  Defined  Requirements 

Requirements  that  remain  unclear  invite  interpretation,  errors  and  rework  once  the 
mistake  is  discovered.  Defining  the  requirements  concretely  is  the  key  to  enabling  the 
right  follow  through  of  activities  in  the  development  process.  Poorly  defined 
requirements  lead  to  deviations  within  the  system,  causing  inefficiencies,  frustration  for 
customers  and  contractors,  and  endangerment  of  the  required  system  performance. 
Unclear  requirements  are  a  major  threat  to  the  development  of  a  good  acquisition 
strategy;  if  assumptions  are  incorrect,  they  lead  to  wrong  decisions  and  poorly  defined 
objectives  for  a  contractor’s  legal  obligations. 
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3. 


Late  Changes  in  the  Acquisition  Process 


Late  changes  and  requirement  creep  are  inevitable  and  endanger  the  success  of  a 
program.  They  occur  frequently  without  being  based  on  changes  to  the  operational  needs. 
Politicians,  the  services,  and  the  users  have  to  understand  that  adding  a  requirement 
means  significant  reengineering  of  the  software  component.  Modem  weapon  systems  are 
sophisticated;  their  physical  design,  software  programs,  multiple  interfaces,  and 
integration  needs  are  not  well  suited  for  late  changes  because  late  changes  can  drive  a 
drastically  different  design  or  solution  causing  significant  reengineering  and  scrap  of 
work  already  completed.  Insisting  on  additional  requirements  often  leads  to  integration 
problems,  high  costs,  and  poorer  system  performance.  In  the  worst  case,  the  system  may 
be  rendered  complete  uselessness32,  but  unfortunately,  understanding  of  the  probable 
impacts  of  late  changes  is  not  widespread. 

4.  Differences  in  Testing  Requirements 

Testing  is  expensive.  This  valuable  part  of  evaluation  in  the  acquisition  process  is 
often  underfunded  because  the  benefits  of  adequate  testing  are  not  fully  understood. 
Thorough  testing  is  not  a  luxury  of  the  program.  It  provides  evidence  that  requirements 
have  been  met,  the  system  works  reliably  and  safely  under  all  conditions.  In  addition  to 
these  aspects  testing  creates  confidence,  and  gathers  data  that  is  essential  to  future 
capability  technological  advancements. 

5.  Lack  of  Mutual  Understanding  about  Operational,  Support  and 
Maintenance  Needs  and  Schedule 

The  government  provides  funding  for  new  systems  to  close  capability  gaps  and 
encounter  threats  to  the  country.  It  also  expects  a  system  to  survive  as  long  as  it  is  needed 
for  its  task.  System  engineers  plan  for  the  system  as  long  as  a  customer  he  intends  to  use 
it. 


32  A  program  that  suffered  from  the  last  three  segments  was  the  A12  A  Avenger  II.  The  program  was 
cancelled  after  only  three  years.  At  that  point  the  aircraft  was  already  two  years  behind  schedule,  1,3 
Billion  dollars  over  cost  and  had  8000  pounds  overweight. 
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Sometimes,  these  life-cycles  are  not  aligned  at  their  beginning.  This  causes  cost 
problems  in  the  use,  reduced  availability  and  life-cycle  of  the  system.  Operational 
requirements  or  conflict  may  cause  a  system  to  be  used  more  than  expected,  which  causes 
accelerated  wear  and  tear,  higher  maintenance  support  efforts,  and  operational  costs 
during  wartime.  These  circumstances  cannot  be  planned  for,  but  cost  expectations  for 
prolonged  life-cycles  and  excessive  use  can  be  calculated  and  predicted.  The  government 
and  services  often  have  goals  for  intended  economic  useful  life  spans,  but  do  not 
communicate  them  to  the  contractor.  This  may  be  unintentional;  they  forget  to  update  the 
information  before  the  program  starts.  It  may  also  be  intentional;  they  know  that  longer 
life-cycles  go  hand-in-hand  with  higher  system-costs.  As  already  stated,  system  and  life 
cycle  costs  can  determine  whether  a  program  is  initiated,  as  well  as  the  total  planned 
number  of  systems  to  acquire.  This  view  is  short  sighted;  the  contractor  should  be 
provided  the  expected  system  life-cycle,  especially  if  it  might  be  considerably  longer33. 
The  following  depiction  shows  that  this  is  not  rare.  Most  systems  are  designed  for  an 
average  life-cycle  of  about  25  to  30  years. 


33  This  basically  applies  to  all  aircrafts  and  many  other  systems  in  use,  see  examples  on  table  1  below. 
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Table  1 .  Aging  Systems  Cause  Supportability  Issues 


Aging  Systems 
Cause  Supportability  Issues 


HEMTT 

SSN  688  - 1 

F-15 - 

F-14  - 


CH-47 
M-113  - 
UH-1  - 

KC-135  — 
AIM-9  — 

C-130  - 

2.5  Ton  Truck  — 
B-52 - 


44  yrs 
56  yrs 
51  yrs 
41  yrs 
71  yrs 

59  yrs 
49  yrs 


86  yrs 
72  yrs 

79  yrs 
67  yrs 
94  yrs 


1940  1950  1960  1970  1980  1990  2000  2010  2020  2030  2040 


Source:  MN3331  lecture  slide,  Professor  Rene  G.  Rendon,  NPS 


The  point  is,  if  a  new  system  stays  in  service  considerably  longer  than  it  was 
designed  for,  there  is  a  major  impact,  especially  on  the  Operations  and  Support  (O  &  S) 
life-cycle  costs  (LCC)  and  supportability34  expenditures.  If  the  contractor  is  aware  of 
planned  system  economic  useful  life,  the  system  design  and  design  for  supportability  will 
likely  be  properly  architected.  In  the  long  run,  this  will  lead  to  a  more  robust  design  that 
allows  for  further  upgrades.  This  can  be  an  essential  factor  for  controlling  the  costs  of 
program  upgrades,  which  can  be  planned  for  technical  refreshment,  mid-life  conversion, 
or  other  life  cycle  considerations.  Communicating  requirements  and  expectations  for 
extended  life-cycles  can  save  significant  operational  and  support  funding  over  the 
extended  life  cycle. 


34  See  also  Systems  Engineering  And  Analysis,  Fourth  edition,  Blanchard/Fab  rye  ky,  p.  542,  Figure 
15.10. 
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6.  Funding  of  Programs 


a.  Budgeting/Funding 

Funding  for  acquisition  programs  is  a  complex  process,  burdened  with 
numerous  laws,  policies,  and  other  guidance  documents.  It  is  also  vital  to  the  program’s 
survival. 

Budgeting  and  the  acquisition  process  are  not  aligned,  and  are  driven  by 
several  factors.  The  cyclical  budgeting  process  schedule  is  fixed,  as  required  by  law. 
Contrary  to  this,  the  schedule  of  an  acquisition  process  is  closely  related  to  ongoing 
developments.  These  different  methods  do  not  mesh  well. 

This  problem  is  addressed,  in  part,  by  multiple  years  of  identified  funding. 
However,  to  determine  how  much  money  is  available  for  a  program,  several  numbers 
must  be  considered  and  calculated:  the  amounts  that  are  available  from  the  different  years 
of  funding,  how  much  has  already  been  spent,  and  how  much  is  actually  needed  for 
successful  completion.  This  system  works  well  for  accounting  and  control  purposes,  but 
is  not  good  for  program  flexibility  and  overall  performance  of  the  acquisition  programs. 
When  there  is  no  funding  available,  and  the  PM  cannot  secure  additional  funding,  a 
program  remains  idle  when  it  could  otherwise  be  progressing  towards  completion. 
Another  problem  arises  when  money  that  is  available  has  been  specified  for  a  specific 
purpose,  known  as  the  “colors  of  money,”35  and  those  specified  purposes  are  different 
than  the  needs  of  the  program.  This  leads  to  an  insufficient  amount  of  funding  to  continue 
development  because  of  the  use  restrictions.  Navigating  the  myriad  of  funding  laws  and 
directives  requires  a  significant  amount  of  management,  reducing  the  amount  of  time 
PMs  have  to  manage  the  system’s  development. 

This  legal  background  causes  another  challenge.  The  preparations  for  the 
beginning  of  an  acquisition  program  must  be  finished  early  enough  to  fit  into  the  fixed 
cycle  of  the  budgeting  process.  Pressure  from  the  services  to  get  programs  started  and 

35  The  expression  “colors  of  money”  refers  to  the  fact  that  any  funding  by  law  is  determined  by 
purpose,  time  and  amount.  The  purpose  is  the  related  appropriation,  often  referred  to  as  color  of  money  and 
has  its  origin  in  Title  31,  USC,  which  is  also  sometimes  referred  to  as  the  “Colors  of  Money”  law. 
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underestimated  preparation  time,  for  things  such  as  requirement  analysis,  sometime  result 
in  a  program  that  is  rushed.  The  haste  to  begin  a  program  is  the  result  of  significant 
pressure:  either  the  program  starts  immediately  or  never.  The  perception  that  deficits  can 
be  fixed  at  later  times  is  almost  always  wrong;  life-cycle  costs  that  are  overoptimistically 
low  improve  chances  of  initial  funding  for  programs.  Over  time,  the  needs  and  practices 
described  in  the  paragraph  above  have  resulted  in  interesting  and  malicious  side-effects. 
Two  common  side-effects  are  burden  shifting36  processes  and  the  implementation  of  a 
misleading  reward  system37.  Both  have  a  negative  impact  on  the  overall  accuracy  and 
trust  of  the  acquisition  process. 

F.  ESSENTIALS  OF  SOFTWARE  ENGINEERING  AND  ACQUISITION 

PROCESS  MANAGEMENT  REQUIREMENTS 

1.  Software  Engineering  Requirements 

The  crucial  needs  of  software  development  are  often  misunderstood.  Clear  and 
well  stated  requirements  are  an  absolute  must  for  the  success  of  any  major  program 
involving  software.  This  applies  to  the  overwhelming  majority  of  modern  systems  as  they 
are  increasingly  software-intensive.  Service  software  has  become  an  elementary  part  of 
virtually  every  program.  The  need  for  clearly  communicated  and  addressed  requirements 
covering  all  functional,  interface,  and  all  current  and  envisioned  interoperability  needs 
are  vital  to  effective  and  efficient  software  development. 

Directly  related  to  this  need  is  a  stable  developmental  environment  that  allows  the 
identification  and  establishment  of  a  framework  that  the  software  and  system  can  operate 
within.  As  systems  become  more  sophisticated  and  complex,  systems  within  systems 
become  more  important.  These  factors  are  major  schedule  and  cost  drivers  and  dependent 
on  software  engineering.  The  keys  to  success  therefore,  include  significant  early  work  in 


36  See  also  Systems  Archetypes  Basics,  Kim  Daniel  H.  and  Anderson  Virginia,  Pegasus 
Communications,  p.  25. 

37  See  also  On  the  folly  of  rewarding  A,  while  hoping  for  B,  Academy  of  Management  Executive  1995 
Vol.  9  No.  1. 
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requirements  analysis,  software  development,  and  effective  management  to  minimize 
changes  to  functional  requirements  and  framework  aspects. 

One  pitfall  is  inadequate  predictions  of  the  amount  of  software  that  will  be  needed 
during  early  system  development.  Coding  of  the  software  itself  is  rarely  a  problem,  but 
late  requirement  and  operational  framework  changes  are  time  consuming,  costly,  and  risk 
not  being  incorporated  during  later  stages  of  development.  Software  development  is  very 
expensive  during  the  early  stages  of  development  (up  to  60%  of  the  overall  software 
development  cost  or  more),  and  can  be  compromised  by  rework  resulting  from  poor 
requirements  analysis,  resulting  in  significant  cost  growth  and  schedule  slips. 

2.  Capability  Requirements 

Capability  requirements  are  an  important  factor  of  system  design  and  are  essential 
for  a  sound  system  engineering  process.  Capability  requirements  are  increasingly 
expressed  in  terms  of  performance  characteristics  and  metrics.  Together  with  functional 
requirements  and  operational  needs,  they  shape  the  preliminary  and  final  design  of  a  new 
system  during  trade-offs  within  the  system  engineering  process.  Identification, 
formulation  and  correct  prioritization  of  these  requirements  are  key  in  developing  the 
overall  abilities,  optimizing  strengths,  and  limiting  weaknesses  of  a  new  system. 
Weighing,  examining,  and  balancing  tradeoffs  in  the  system  engineering  process  is  part 
of  the  analysis  of  alternatives. 

The  problem  is  poor  communication  among  the  services  regarding  the  functional 
and  operational  requirements.  They  do  not  focus  enough  on  tradeoffs  and  their 
consequences  on  the  system  design.  Instead,  the  responsibility  lies  in  the  contractor’s 
system  engineering  process,  whose  results  depend  on  the  interaction  between  IPTs38. 


38  See  also  Developing  Software  Requirements  Supporting  Open  Architecture  Performance  Goals  in 
Critical  DoD  System-of-Systems,  Naegle  Brad,  pp.  13-16. 
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3.  Safety  Requirements 


Safety  requirements  of  new  systems  repeatedly  represent  a  common  pitfall  for  the 
acquisition  process.  Sometimes,  safety  requirements  are  forgotten,  poorly  communicated, 
or  assumed  to  be  a  software  engineering  environment. 

Unfortunately  there  are  a  lot  of  programs  that  tell  a  different  story.  A  system  is 
safely  handled  when  data  transfer  is  secure  and  is  robust  against  electronic 
countermeasures,  hacking,  and  spooling.  These  needs  must  be  satisfied  in  an  environment 
where  equipment  used  by  ground  forces  has  a  high  risk  falling  into  the  hands  of  the 
enemy39. 

4.  Interoperability  and  Interface  Requirements 

The  operational  framework  is  the  most  influential  factor  in  determining  the 
nature,  complexity,  and  number  of  interfaces  and  interoperability  needs.  The  operational 
environment  in  modem  warfare  is  very  complex  and  inhibits  joint  aspects,  at  least  at  the 
national  Services  level  and  below.  More  often,  another  level  of  complexity  like 
interoperability  with  allied  forces,  is  created  by  the  net-centric  nature  of  command  and 
control  systems  and  data  processing  systems,  which  aid  the  decision  making  of  Combat 
Commanders  and  political  leaders.  The  recipe  for  sound  interoperability  and  reliable, 
robust  interfaces  is  the  selection  of  a  correct  work  sequence.  The  easiest  way  to  achieve 
this  goal  is  to  begin  laying  out  the  operating  framework  of  the  new  system.  The  goal  of 
the  framework  is  sometimes  not  completely  communicated,  verified  or  accurately 
examined,  which  leads  to  problems  in  integration,  interface  suitability,  and  causes  time 
consuming  and  costly  design  changes  late  in  the  acquisition  process.  Once  the  complete 
requirements  framework  is  established,  the  design  of  individual  components,  subsystems 
and  systems-of-systems  within  this  framework  becomes  easier  and  less  risky. 
Interoperability  aspects  and  interfaces  become  more  transparent  and  obvious;  the  amount 
of  misinterpretations  and  unidentified  needs  are  considerably  reduced.  The  numbers  of 
systems  or  system-of-systems  that  must  interface  in  the  depicted  operational  environment 

39  See  also  Developing  Software  Requirements  Supporting  Open  Architecture  Performance  Goals  in 
Critical  DoD  System-of-Systems,  Naegle  Brad,  p.  24 
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and  network  sometimes  face  the  challenge  of  incorporating  legacy  systems  and 
equipment  that  was  not  designed  for  upgradeability  or  interoperability  within  the 
operational  framework  of  modem  warfare.  Although  most  of  the  newer  systems  use  an 
open-system-architecture  to  allow  future  changes,  as  conceivable  in  a  significant  time 
horizon,  some  of  the  legacy  systems  are  difficult  to  integrate  at  all,  or  need  significant, 
expensive  redesigns  in  order  to  adapt  to  current  standards.  This  is  evident  for  every 
system  incorporating  only  a  small  amount  of  software  consisting  of  obsolete  or 
unsupportable  program  languages,  or  simply  did  not  allowing  for  extensions  of  relatively 
simple  features  like  more  throughput  and  memory. 

5.  Upgrade  Requirements 

There  are  tools  and  processes  available  that  help  to  identify  and  determine  various 
needs  for  software  development.  The  Modular  Open  Systems  Approach40  helps  to 
identify  required  interfaces.  System  engineers  define  areas  where  software  support  is 
needed  to  achieve  system  performance  that  can  not  or  should  not  be  represented  by 
hardware.  Modelling  and  simulation  tools  and  software  developing  programs  help  to 
illustrate  the  complexity,  total  amount  of  software  needed  and  how  it  might  look  like. 
This  allows  Program  Managers  and  contractors  to  evaluate  how  suitable  the  software  will 
be  for  the  requirements  stated  and  the  amount  and  size  of  upgrades  that  might  be  needed 
over  the  life-cycle  of  the  new  system.  The  Modular  Open  Systems  Approach  (MOSA), 
consequent  use  of  system  engineering  processes  and  a  great  variety  of  available  software 
programs  help  to  define  how  complex  the  new  system  will  be.  This  allows  system 
engineers,  Program  Managers,  contractors  also  how  complex  the  software  package  will 
be  that  is  needed  to  satisfy  the  needs  for  interoperability,  interfaces  and  upgradeability  for 
the  new  system.  The  standards  and  metrics  for  software  development  do  not  match  those 
of  hardware.  However,  compared  to  the  80s  and  90s,  there  is  a  better  understanding  of 
software  development’s  needs  and  underlying  processes.  Examples  of  this  are  the  older 
metrics  of  software  lines  of  code  (SLOC),  which  become  increasingly  replaced  by 


40  See  also  “Using  a  Modular  Open  Systems  Approach  in  Defense  Acquisitions”,  Dr.  Rene  Rendon, 
pp.  17-19. 
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metrics  of  functional  points  that  are  more  meaningful.  Quality  of  software  development 
has  become  vital  to  the  interaction  of  information  and  first-move  abilities  on  the 
battleground. 


6.  Life-Cycle  Requirements 

Software  development  and  requirements  have  an  important  impact  a  system’s  life- 
cycle.  Software  requirements  are  likely  to  change  over  the  life-cycle  of  the  system.  If  a 
good  software  developmental  process  is  in  place,  this  should  not  be  an  issue,  but  their 
consequences  can  become  one  if  not  considered  at  the  start  of  a  program. 

The  military  often  uses  their  systems  over  an  extended  life-cycle.  This  is  different 
from  the  commercial  world,  where  special  and  operational  availability  needs  lead  to 
expensive  systems. 

Software  development  does  not  end  with  the  delivery  of  a  new  system.  There  is 
always  the  need  to  adapt  to  new  operational  aspects,  lessons  learned  by  the  users  after 
testing,  suggestions  for  improvement,  new  technology,  and  changes  in  interoperability.  A 
second  set  of  common  challenges  for  software  requirements  relate  to  the  supportability 
and  maintainability  of  the  software.  The  software  language  used,  proprietary  rights  of  the 
software  to  develop  the  new  system,  and  costs  of  maintaining  the  complete  life-cycle  are 
sometimes  not  given  enough  consideration.  This  leads  to  repercussions  for  the  overall 
life-cycle  expenses,  security  needs  of  the  software,  updated  availability,  restrictions  for 
full  and  open  competition,  and  other  factors.  Long  term  access  to  the  development  codes 
for  new  software,  proprietary  rights,  and  security  aspects  must  therefore  be  a  mandatory 
consideration  of  all  programs  that  use  embedded  software  or  software  intensive 
applications. 

G.  ACQUISITION  PROCESS  &  MANAGEMENT  REQUIREMENTS 

1.  Capability  Requirements 

Capability  requirements  are  not  only  of  crucial  importance  for  software  as  already 
described  earlier.  All  requirements  that  try  to  describe  the  capabilities  of  the  new  system 
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are  extremely  sensitive  for  the  overall  achievements  and  operational  success  of  the  new 
system.  These  requirements  should  be  performance  based  to  allow  a  maximum  of 
contractor  creativity.  They  also  should  be  related  to  metrics  that  can  be  easily  evaluated 
and  verified  during  developmental,  operational  and  life-firing  testing  as  the  program 
moves  towards  fielding.  If  stated  and  prioritized  correctly  these  requirements  define  the 
suitability  and  effectiveness  of  the  new  system  and  will  contribute  largely  to  its  overall 
performance.  Necessary  trade  offs  have  to  represent  the  priorities  of  the  customer  and 
should  be  verified  as  decisions  are  necessary  to  shape  the  design  and  best  solution  to 
close  the  detected  capability  gap.  All  design  changes  with  the  exception  of  safety  needs 
should  be  made  prior  the  critical  design  review  as  late  changes  have  a  huge  negative 
impact  on  cost  and  schedule. 

There  are  two  decisive  aspects  that  will  have  a  major  impact  on  the  overall  cost, 
performance  and  suitability  of  the  new  system.  First,  all  requirements  must  be  directly 
traceable  to  functional  or  operational  needs.  Second,  the  user  must  be  aware  of  how 
different  prioritization  of  those  two  sets  of  requirements  interacts  with  the  system 
engineering  process  during  the  design  tradeoffs,  influencing  cost,  performance,  and 
suitability  of  the  system  as  a  whole.  Chain  of  Command,  users,  technical,  operational 
experts,  logistical  experts,  contractors  and  IPTs  must  agree  before  developing  a  new 
system  that  addresses  all  requirements  and  delivers  the  best  economical  solution  possible 
to  the  warfighter.  The  overall  suitability  and  performance  of  the  system  are  compromised 
by  too  many  opinions  on  the  importance  of  single  requirements.  This  can  also  lead  to 
unnecessary  costs. 

The  method  of  current  requirement  generation  gives  more  weight  to  this 
argument.  The  top-down  Joint  Capabilities  Integration  &  Development  System  (JCIDS) 
and  Joint  Requirements  Oversight  Council  (JROC)  do  not  include  enough  input  from  the 
Combatant  Commanders  regarding  functional  and  operational  needs  for  a  new  program. 
These  inputs  are  not  included  in  the  acquisition  process  until  too  late,  when  they  lead  to 
requirement,  software,  and  design  changes.  This  process  is  inefficient,  expensive,  and 
adds  an  early  and  unnecessary  risk  in  cost  growth  and  schedule  slips.  Starting  with 
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correct  requirements  and  a  relevant  set  of  metrics  for  all  functional  and  performance 
aspects  of  aligned  system  requirements  is  necessary  for  effective  and  efficient  use  of  the 
available  budget. 

2.  Cost  Control  and  Transparency 

Cost  control  and  transparency  are  necessary  for  proper  planning  of  the  acquisition 
process  and  adequate  stewardship  of  taxpayer.  Congress,  major  defense  contractors, 
Services,  user  communities,  program  managers  and  contracting  experts  agree  that  control 
and  transparency  of  cost  is  necessary. 

There  is  a  lack  of  enforcement  procedures,  proper  group  and  individual 
accountability,  and  rewards  for  cost-conscience  behaviour.  As  a  consequence,  regulations 
and  tools  are  in  place  for  a  lot  of  partial  processes  attempting  to  maintain  close  cost 
control  and  visibility,  but  these  are  sometimes  are  not  well-understood  nor  strictly 
followed.  Unwittingly,  these  measures  are  neglected  and  at  times,  purposely 
circumvented  to  reach  individual  goals. 

3.  Program  Documentation  Requirements 

The  documentation  for  a  major  program  has  become  a  large  burden  in  the 
acquisition  process.  Proper  documentation  is  clearly  beneficial  and  necessary,  but  it  does 
hinder  the  acquisition  process  and  contribute  to  higher  program  costs.  This  was  especially 
true  from  the  late  eighties  until  the  beginning  of  the  21st  century,  before  documentation 
efforts  shifted  towards  electronic  media,  which  is  easier  to  change  and  does  not  incur 
high  costs  from  reprints.  Too  much  pressure  on  acquisition  programs  often  leads  to  slips 
in  proper  documentation  and  any  delay  in  documentation  deliveries  is  usually  a  sign  of  a 
an  over-worked  staff  struggling  to  keep  up  with  the  documentation  requirements  while 
managing  the  development  of  complex  systems. 

4.  Legal  Requirements 

The  flood  of  legal  statuaries,  regulations,  and  guidelines  has  become  a  definite 
challenge  to  the  acquisition  workforce.  Program  Managers  must  understand  the  variety, 
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and  impact,  of  legal  restrictions  that  apply  to  their  program.  They  must  work  closely 
together  with  a  diminished  and  less  experienced  contracting  workforce  to  make  sure  the 
contract  for  the  new  acquisition  conforms  to  all  regulations  and  legal  restrictions.  The 
requirements  have  been  developed  by  the  IPTs  to  meet  acquisition  process  goals,  so  that 
troops  receive  the  best,  affordable  technical  solutions  as  soon  as  possible.  Now  these 
requirements  have  to  be  transfonned  into  a  binding  legal  contract  that  is  free  of  arbitrary 
formulations,  contains  all  infonnation  needed  by  the  contractor  and  incorporates  all 
performance  based  metrics  that  are  essential  for  the  program.  This  is  a  challenging  task 
and  a  decisive  phase  of  the  acquisition  process. 

Especially  when  requirements  or  important  performance  parameters  are  not  met 
by  contractors,  a  contract  can  be  the  only  leverage  available  to  the  government,  so  it 
needs  to  be  clear.  Developing  necessary  requirements  and  articulating  them  clearly  to 
different  stakeholders  is  very  difficult,  even  if  this  process  was  well  planned  and 
successfully  implemented  into  the  request  for  proposal  (RFP).  A  sufficient  level  of  work 
breakdown  structure  (WBS)  in  the  solicitation  and  contracting  documents  is  just  as 
important.  Both  processes  need  a  sufficient  schedule  to  support  development  success 
during  the  rest  of  procurement. 

Environments  for  the  acquisition  process  are  different.  They  span  from  stable, 
well  planned  system  replacements,  to  contingency  contracts.  These  environments  can 
incorporate  the  need  for  complex  systems,  a  research  effort  to  make  new  cutting  edge 
technologies  mature  enough  to  use  for  defense  needs.  Those  environments  include 
unstable  and  rapidly  changing  environments  like  unconventional  warfare,  terrorism  and 
other  new  global  challenges.  .  This  is  the  reason  why  the  legal  framework  must  allow 
several  approaches  for  acquisition  procedures  &  processes,  and  several  levels  of 
competition  and  contracting  methodologies  to  accommodate  different  situations. 

This  does  not  only  apply  to  current  legal  restrictions,  but  also  to  basic  regulations 
and  laws  that  hamper  full  and  open  competition.  Analysis  of  alternatives  (AoA)  is  one 
step  that  benefits  from  the  system  engineering  process.  This  powerful  tool  for 
competition  should  not  be  compromised  by  legal  restrictions  if  there  are  other  options  for 
addressing  security  and  national  interests. 
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5. 


Operational  and  Performance  Requirements 


Realistic  and  measurable  formulation  of  operational  and  performance 
requirements  is  vital  to  the  acquisition  process.  Late  design  changes,  bad  trade-off 
decisions,  delays,  and  cost  and  schedule  overruns  are  almost  inevitable  if  requirements 
are  not  fully  formulated.  For  the  purpose,  there  is  no  difference  between  traditional 
development,  commercial  off  the  shelf  (COTS),  or  non  developmental  items  (NDI).  A 
wrong  classification  of  COTS  or  NDI  due  to  poorly  defined  or  lack  of  requirements  will 
have  tremendous  impact  on  the  cost,  schedule,  and  performance  of  the  envisioned  system 
acquisition.  There  were  expensive  and  painful  experiences  during  the  aircraft  T-45  and  A 
12  procurement.4142 

Realistic  and  measurable  operational  and  perfonnance  requirements  formulation 
is  vital  part  of  the  acquisition  process.  Without  enough  effort  on  this  basic  early  step, 
changes,  late  design  changes,  bad  tradeoffs,  delays  cost  and  schedule  overruns  are  almost 
inevitable  and  just  a  matter  of  time  to  occur  within  the  program.  There  is  no  difference 
for  this  section  whether  we  talk  about  traditional  development  or  commercial  off  the  shelf 
(COTS)  or  non  developmental  items  (NDI).  A  wrong  classification  of  a  system  as  COTS 
or  NDI  due  to  poorly  defined  requirements  or  lack  of  requirements  analysis  will  have  a 
tremendous  impact  on  cost  schedule  and  performance  of  the  envisioned  acquisition  of  a 
system. 


6.  Maintenance  and  Supportability  Requirements 

The  reality  of  acquisition  reveals  that  if  a  program  comes  under  funding  pressure, 
whether  due  to  cost  or  schedule  overruns,  there  are  usually  two  reactions.  What  is  likely 
to  happen  first  is  a  reduction  of  the  program’s  unit  numbers43. 


41  See  „The  T45  T/S  A  Case  Study”,  GB  4450/MN4470. 

42  As  stated  in  a  brief  on  system  engineering  lessons  learned  from  different  programs  during  SI40 1 1 
class,  May  2007. 

43  See  as  an  example  change  in  production  numbers  for  the  F  35  JSF. 
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Table  2.  Changes  in  JSF  Program  Purchase  Quantities  and  Costs 


October 
2001  (system 

November  1996(program  start)  development  start) 

December 

2003a 

(rebaseline) 

December  2005a(latest 
available  data) 

Expected  Quantities 

Development  quantities 

10 

14 

14 

15 

Procurement  quantities  (U.S.  only) 

2,978 

2,852 

2,443 

2,443 

Total  Quantities 

2,988 

2,866 

2,457 

2,458 

Cost  Estimates  (Then  Year  $  in  billions) 

Development 

$24.8 

$34.4 

$44.8 

$44.5 

Procurement 

Not  available 

196.6 

199.8 

231.7 

Other 

Not  available 

2.0 

0.2 

0.2 

Total  Program  Acquisition 

Not  available 

$233.0 

$244.8 

$276. 5b 

Unit  Cost  Estimates  (Then  Year  $  in  millions) 

Program  acquisition 

Not  available 

$81 

$100 

$112 

Average  procurement 

Not  available 

69 

82 

95 

Estimated  Delivery  Dates 

First  operational  aircraft  delivery 

2007 

2008 

2009 

2009 

Initial  operational  capability 

2010 

2010-2012 

2012-2013 

2012- 

2015c 

Source:  GAO  Report  07-360,  p.  5 

This  strategy  leads  to  less  cost  savings  than  anticipated  due  its  negative  impact  on 
This  is  partially  caused  by  spreading  the  fixed  cost  on  fewer  units  but  also  by  changing 
stress  levels  on  material  and  increased  times  of  operation  for  those  units.  This  can  lead  to 
increased  life-cycle  cost  and  is  unfortunately  not  given  enough  thought.  Programs 
experiencing  a  substantial  cut  in  production  numbers  typically  lead  to  unit  costs  that  were 
higher  than  originally  envisioned44.  This  should  never  happen  for  short  term  savings. 
Cuts  in  procurement  numbers  are  very  common  and  can  be  an  indicator  of  an 
incomprehensive  and  short-sighted  view  of  these  cuts’  effects  on  the  acquisition  costs 
because  they  have  a  major  impact  on  the  costs  of  long  term  lifecycles.  Operational 
availability  of  the  system  will  be  lower  as  the  flight  hours  on  single  units  will  be  higher 
and  result  in  more  failures  than  envisioned.  As  there  are  fewer  units  used  over  a  longer 
period  as  planned,  maintenance  turn-around  time  will  be  longer  as  higher  stress  is  placed 
on  the  material.  An  insufficient  level  of  spare  parts  might  even  be  an  additional 
consequence  of  an  increased  burden  on  the  material.  A  significant  cut  in  numbers 
combined  with  a  false  estimated  reliability  between  failures  can  even  lead  to  a  temporary 


44  See  Joint  Strike  Fighter  program  as  an  example  (GAO  report  07-360,  p.  5,  7. 
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or  constant  unavailability  of  the  new  system.  In  addition  to  this  problem  the  life-cycle 
cost  for  legacy  systems  might  also  increase  due  to  higher  maintenance  cost  as  they  have 
to  be  kept  in  service  until  a  certain  number  of  the  new  system  replacing  it  is  available. 

H.  CHALLENGES  &  OPPORTUNITIES 

1.  Flexible  Budgets 

Changing  the  budgeting  process  and  funding  laws  is  difficult  to  achieve,  but  smart 
decisions  in  this  area  save  taxpayer’s  money  and  reap  huge  benefits.  Some  changes  can 
be  implemented  over  time  if  the  impacts  and  consequences  of  the  suggestions  are 
understood  and  properly  addressed. 

Sub-optimized  practices  and  relationships  contribute  to  the  waste  of  resources  and 
reward  system  inefficiencies.  The  schedule  driven  budget  cycle  must  support  the  event 
driven  acquisition  cycle  more  functionally.  This  includes  the  necessary  amendments  to 
budgeting  laws  and  procedures,  which  will  eliminate  waste  in  the  current  processes. 
There  must  be  incentives  for  all  stakeholders,  including  members  of  Congress,  major 
defense  contractors,  the  Services,  and  the  acquisition  community,  to  make  the  right 
decisions,  encourage  honest  and  accurate  estimations,  and  reward  the  efficient  use  of 
taxpayer  money. 

2.  Higher  Accountability  for  Services 

The  Services  must  take  more  pride  in  their  ownership  of  new  programs. 
Warfighters  need  support  throughout  the  procurement  process  in  order  to  deliver  a  usable 
solution,  or  “best  bang  for  the  buck”  systems.  Because  overall  numbers  decline  and 
manpower  resources  become  scarce,  there  must  be  enough  capabilities  to  assign  users  to 
the  different  programs  and  involve  them  early.  This  also  applies  to  Combatant 
Commanders,  whose  contributions  in  requirement  generation,  evaluation  and  testing  are 
mandatory  to  quickly  detect  misfits,  design  miscues,  and  suitability  issues.  This  is  a  vital 
role  in  the  success  of  the  program. 
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The  current  fight  over  different  concepts  and  popular  programs  hurts  the  Services 
and  users  more  than  anything  else.  Once  supplementary  funding  is  deeply  curtailed  or 
eliminated,  the  distribution  fight  among  the  Services  will  intensify.  The  Services  must 
understand  that  this  behaviour  is  not  helpful  to  anyone.  Duplicate  capabilities  are  a  waste 
of  resources  and  should  be  reduced  or  eliminated.  The  efforts  to  achieve  the  desired  joint 
capabilities  must  be  aligned.  This  would  allow  the  Services  to  contribute  their  strengths 
and  share  the  burdens  and  responsibilities  of  modem  warfare  equally.  The  solution  is  to 
stop  fighting  over  resources. 

This  competition  over  funding  can  appear  to  be  driven  by  parochial  interests 
rather  than  any  real  warfighter  need.  This  mode  of  thought  is  counterproductive  to 
achieving  weapon  systems  that  are  flexible  and  capable  enough  to  meet  the  future  needs 
of  net-centric  warfare  and  increased  interdependencies.  The  pride  of  the  Services  cannot 
come  before  the  best  interests  of  the  warfighters  and  taxpayers  in  decision  making. 
Increasing  monetary  pressures  will  be  a  decisive  factor  driving  a  development  within  the 
civilian  and  political  environment  into  a  healthier  direction  based  on  the  real  needs  of  the 
Services  over  time. 

3.  Less  Misuse  of  the  Funding  and  Acquisition  Processes 

The  Services  and  their  acquisition  forces  are  the  least  powerful  stakeholders  in  the 
acquisition  process.  Nevertheless,  they  are  assigned  responsibility  whenever  an  error 
occurs  in  a  procurement  program.  This  is  true  no  matter  whether  it  is  Congress  cutting 
funding  in  an  irresponsible  way,  contractors  trying  to  maximize  profits  on  an  ambiguous 
contract,  or  if  the  user/combat  developer  communities  are  providing  poor  program 
requirements. 

The  acquisition  workforce  itself  has  made  the  best  of  this  situation  inventively. 
There  are  many  bad  practices  that  can  be  observed  throughout  various  programs. 
Program  Managers  and  contractors  start  their  programs  with  overoptimistic  assumptions 
regarding  their  schedule  and  cost.  Once  the  program  starts  and  the  first  problems  appear 
they  are  quite  often  ignored  and  not  aggressively  addressed.  This  happens  because  some 
contractors  and  Program  Managers  did  not  expect  to  deal  with  a  difficult  situation  early 
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in  the  acquisition  process  and  fear  for  their  program.  This  tends  to  happen  especially  if  a 
major  problem  surfaces  at  this  early  stage  of  the  process  that  might  result  in  a 
cancellation  of  the  program  or  major  cut  to  it’s  funding..  Unfortunately,  this  causes  the 
problem  to  arise  later,  when  it  is  too  late  to  solve  or  too  costly  to  redesign.  The  contractor 
is  not  interested  in  disclosing  the  problem  until  production  because  the  program  might  be 
cancelled  early,  and  usually  does  not  make  any  significant  profit  until  the  production 
phase.  The  result  of  this  delayed  fault  detection  and  recovery  is  late  design  changes, 
which  overruns  cost  and  schedule. 

Program  managers  have  learned  how  to  get  support  for  their  programs,  establish 
connections  with  members  of  the  Congress.  They  know  how  to  drain  funding  from 
programs  that  suffer  for  any  reason  or  can  not  spend  their  appropriated  funding  within  the 
given  time  constraints.  While  other,  less  experienced  programs  are  hammered  for  cost 
and  schedule  overruns,  program  managers  gain  additional  reserves  for  small  uncertainties 
and  glitches  in  their  program. 

At  the  end  of  the  fiscal  year,  every  Program  Manager  prepares  contingency  plans. 
They  include  preparation  of  contracts  they  could  sign  immediately  to  spend  money  that 
other  programs  were  not  able  to  contract  could  not  before  the  accounts  expired. 

4.  Better  Quality  for  the  Warfighters 

Every  stakeholder  should  behave  in  the  best  interest  of  the  overarching  goal  to 
achieve  the  best  possible  results  for  affordable  warfighter  capability.  The  goal  of  the 
acquisition  process  is  to  deliver  the  most  suitable,  capable,  affordable,  and  current 
solution  to  the  warfighter.  This  calls  for  robust  designs  resulting  in  high  quality  products 
that  are  easy  to  maintain,  support  and  dispose  of.  Accurate  requirements,  incentives,  and 
flexible  rules  and  regulations  are  powerful  tools  that  contribute  to  this  task;  small  changes 
in  attitude  and  behaviour  can  also  make  a  significant  difference  in  estimations  of  cost  and 
schedule,  and  boost  performance  for  the  new  systems  needed.  Aligned  software  and 
hardware  requirements,  and  strategic  partnerships  among  all  stakeholders,  will  deliver 
better  quality,  more  quickly,  and  at  lower  prices  to  customers. 
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5. 


More  Trust  in  the  System 


Re-establishing  a  flow  of  processes  that  are  transparent  and  meet  the  goals  of  the 
acquisition  process,  the  current  debate  over  programs  that  are  more  expensive  and 
prolonged  than  originally  planned  must  be  ended.  Huge  organizations  like  the  DoD  adapt 
slowly,  and  inhibit  change.  It  is  necessary  that  incentives,  which  are  generally  slow,  do 
not  cannibalize  strengths  as  a  price  of  change. 

I.  CONCLUSIONS 

The  generation  and  alignment  of  requirements  for  software  and  hardware  for  new 
major  defense  programs  are  complex  processes  themselves.  Aligning  requirements 
among  the  different  stakeholders  within  an  organization  as  large  and  diverse  as  the 
Department  of  Defense  is  difficult  and  requires  the  understanding  of  the  stakeholders 
with  regard  to  their  contribution,  role  and  responsibility  in  the  acquisition  process.  Key 
stakeholders  outside  of  DoD,  like  members  of  Congress,  the  Media,  and  Lobbyists  make 
it  even  more  difficult  for  the  acquisition  community  to  deliver  effective  and  suitable 
capabilities  to  warfighters.  Nevertheless  requirements  generation,  implementation  and 
verification  will  remain  one  of  the  major  challenges  for  the  future.  It  will  be  decisive  to 
change  current  procedures  to  allow  a  better  preparation  of  this  essential  work  before  the 
start  and  contracting  of  new  programs. 

No  new  regulation,  changed  process,  or  single  source  can  solve  the  challenges  of 
this  unique  business  environment.  It  will  be  individual  stakeholders  who  will  create  a 
successful  and  efficient  program.  Their  passion  and  supportive  interaction  is  what  will 
make  a  real  difference.  The  acquisition  workforce  will  need  tools  that  are  flexible  enough 
to  deal  with  long  term  planned  replacement  of  systems,  urgent  battlefield  needs, 
commercial  items  acquisition  and  contingency  acquisition  at  the  same  time.  The  legal 
framework  has  to  allow  this  flexibility,  maintain  contractor  oversight  and  foster 
competition 

A  variety  of  new,  different  approaches  are  discussed  below  in  the 
recommendation  section.  Only  a  mix  of  the  effort,  honesty,  willingness,  and  cooperation 
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of  individuals  in  the  acquisition  process  will  create  positive  change.  As  an  additional 
challenge,  there  is  a  common  resistance  to  change  in  organizations.  There  are  also 
tradeoffs  in  their  organizational  structure  and  ability  to  support  attributes  like  efficiency, 
adaptability  and  creativity.  The  Acquisition  workforce  has  to  be  big  and  experienced 
enough  to  deal  with  these  challenges  and  should  be  allowed  to  operate  in  an  environment 
that  imposes  as  few  legal  restrictions  as  possible  but  enough  guidance  to  focus  on 
efficient  use  of  taxpayer  money  and  high  quality  products  for  their  customers.  This 
approach  will  increase  individual  responsibilities  on  one  hand  and  accountability  for 
decisions  and  actions  on  the  other  hand. 

J.  RECOMMENDATIONS 

1.  Software  Requirements  and  Software  Development 

a.  Software  Planning  and  Requirements  Formulation 

Software  planning  and  requirements  formulation  are  a  very  tough  tasks.  It 
is  common  for  the  complexity  of  functional  needs  and  environments  to  be  partially 
unknown  in  the  early  phases  of  software  planning.  The  formulation  of  requirements 
involves  at  least  some  insight  into  the  actual  coding  language  and  processes.  .  This  is 
important  not  so  much  which  language  is  actually  used  for  coding  but  to  ensure  the 
coding  language  is  sate  of  the  art  and  will  be  sustainable  over  the  envisioned  lifetime  of 
the  new  system.  The  most  time  and  money  goes  into  configuring  the  architectural 
framework  and  laying  out  the  software  design  this  complex  process  to  sort  out  the 
functional  needs  that  will  be  represented  by  the  software,  needed  interfaces  and  data 
flow,  amounts,  and  interdependencies.  Coding  is  usually  a  minor  problem.  This  can 
easily  lead  to  the  misperception  that  coding  immediately  produces  the  expected  results, 
but  this  is  not  the  case.  To  verify  that  the  software  meets  the  actual  needs  a  considerable 
amount  of  testing  is  still  mandatory. 

Testing  is  important.  To  achieve  reliable  results  in  coding,  the  rule  of 
thumb  is  “code  a  little,  test  a  lot.”  Statistics  can  be  discouraging;  software  development 
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lacks  history  and  experience  when  compared  to  most  hardware  development,  which  uses 
mature  processes  and  metrics.  The  software  environment  is  immature. 

There  is  professional  help  available  to  provide  competent  assistance  with 
the  software  development  challenge.  A  major  professional  institution  to  assist  is  the 
Software  Engineering  Institute45.  This  organization  is  federally  funded  and  can  provide  a 
lot  of  assistance  in  a  great  variety  of  developing  and  interoperability  aspects  of  a  major 
program.  It  should  be  used,  which  is  the  first  recommendation.  Seeking  help  from 
commercial  programs,  information  websites,  and  federally  funded  institutions  like  the 
SEI  can  help  accommodate  the  special  needs  for  a  program.  A  small  variety  of  available 
software  tools  is  listed  in  Table  6,  but  there  are  many  more  possibilities  for  assistance  or 
obtaining  a  deeper  insight  into  software  development  techniques. 

The  second  recommendation  is  to  develop  an  IPT  that  allows  the  software 
developer  to  obtain  all  information  necessary  about  the  operational  background  of  the 
new  system.  Contrary  to  the  current  JCIDS  process,  this  information  should  be  obtained 
by  the  combatant  commanders,  who  are  most  familiar  with  user  needs,  and  approved  in 
the  JCIDS  process.  This  will  ensure  alignment  with  military  doctrine  as  well  as  joint  and 
net-centric  perspectives.  The  detected  capability  gap  will  be  more  understood  and 
articulated  and  redundant  capabilities  within  the  Services  will  no  longer  be  produced. 

After  the  operational  requirements  are  fully  developed,  there  must  be  a 
constant  exchange  of  information  between  the  users  and  the  software  developers  so  that 
any  identified  requirements  changes  are  discovered  early  in  the  process,  before 
significant  reengineering  is  required. 

b.  Contractors,  Software  Development  and  Coding 

Software  development  requires  an  experienced  and  mature  developer. 
Software  developers  should  be  comfortable  with  the  prime  contractor’s  specific 
environment  as  well  as  the  unique  governmental  needs  and  procedures.  This  can  be 


45  Software  Engineering  Institute,  http://www.sei.cmu.edu/  ast.  Last  accessed  February  2008. 
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achieved  by  fostering  strategic  partnerships  with  the  few  contractors  who  have  proven  to 
be  capable  of  producing  results  that  meet  the  needs  of  the  government. 

Another  need  is  an  IPT  of  users  and  software  coders.  This  is  required  to 
maintain  close  control  of  the  software  development  and  provide  software  coders  with 
necessary  information  about  integration,  common,  current  systems,  and  data  presentation 
and  exchange  for  facilitate  effective  software.  Better  results  will  be  produced  with  less 
training  for  the  new  system,  and  therefore  the  numbers  and  size  of  errors,  changes  and 
late  modifications  to  the  user’s  requirements  will  be  reduced. 

Applying  software  metrics  to  this  phase  is  also  necessary.  The  contractor 
must  be  aware  that  his  efforts  to  develop  the  software  are  appreciated,  but  also  that 
inefficient  procedures,  excessive  coding  scrap,  and  poor  results  are  not  acceptable.  This 
includes  a  metric  for  suitable  an  efficient  coding.  SLOCs  are  no  longer  an  effective 
metric  for  software  development.  Numbers  of  functional  points  or  other  functionally 
oriented  metrics  are  now  used.  An  even  better  ratio  of  functional  points  represented  by 
lines  of  codes  used  to  achieve  this  goal  should  be  requested.  However,  this  ratio  will  be 
different  depending  on  the  maturity  of  the  technique  that  must  be  represented,  moved, 
provide  data,  or  aid  decisions.  Nevertheless,  this  thought  can  be  captured  in  a  matrix,  and 
better  efficiency  can  be  requested  as  part  of  a  long  term,  strategic  partnership.  Incentives 
for  efficient  coding  and  thorough  testing  will  produce  faster  results  with  higher  quality. 

c.  Software  Security  and  Maintenance 

Software  security  and  maintenance  are  valid  concerns  in  every  major 
weapon,  information,  and  network  system.  A  lot  of  emphasis  is  placed  on  establishing 
joint  and  net-centric  warfare  capabilities  for  warfighters.  Large,  complex  networks, 
information  systems,  and  data  handling  systems  are  especially  vulnerable  to  espionage, 
hacking,  spoofing,  electronic  countenneasures  and  exposure  to  the  enemy.  This  applies 
particularly  to  ground  and  airborne  systems.  High  value  targets  must  be  protected  during 
wartime  from  any  deterioration  of  capabilities  to  maintain  infonnation  superiority  and 
provide  soldiers  with  the  ability  to  make  decisions,  move  first,  and  take  advantage  of 
surprise.  This  goal  can  be  achieved  by  protecting  crucial  systems  like  satellites,  networks, 
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and  internet.  These  systems  should  be  virtually  unbreakable  so  they  are  always  available 
when  needed.  Another  method  of  achieving  this  is,  once  the  network  is  safe,  is  to  allow 
small  software  updates  that  are  not  downward  compatible  and  protected. 

2.  Operational  and  Functional  Hardware  Requirements 

a.  Requirements  Formulation 

Operational  and  functional  requirement  formulation  must  be  the  job  of 
experienced  users  on  the  battlefield.  Combatant  Commanders,  pilots,  and  platoon  leaders 
are  good  examples.  The  operational  aspect  is  best  represented  by  the  Combatant 
Commanders  level;  functional  needs  are  closely  related  to  users  like  pilots  and  leaders  on 
the  ground. 

The  Combatant  Commanders  have  a  significant  role  in  formulating 
requirements.  They  distinguish  actual  “needs”  from  “nice  to  have”  demands.  They  are  the 
most  suitable  individuals  for  this  decision  because  they  have  the  required  level  of 
operational  insight  and  are  near  enough  to  the  battlefield  that  they  will  not  cut  out 
essential  attributes  needed  for  success  in  the  intended  environment.  However,  Combatant 
Commanders  do  not  have  enough  time  to  explicitly  draft  requirements  for  closing 
detected  capability  gaps.  This  problem  could  be  solved  if  requirement  specialists  were 
easily  accessible  to  them.  The  specialist  would  prepare  preliminary  performance 
specifications  to  be  reviewed  by  the  Combatant  Commander  and  JCIDS  process. 

b.  Requirements/Implementation 

Requirements  can  be  difficult  to  grasp,  fonnulize  or  phrase.  It  is  even 
more  difficult  to  translate  requirements  into  a  language  that  leaves  no  room  for  ambiguity 
and  gives  contractors  all  the  information  necessary  to  understand  the  operational 
environment,  complexity  of  work,  and  technological  risks  involved  in  the  new  system. 

The  first  recommendation  is  to  use  contracting  specialists.  Once  a 
requirement  is  clear  and  approved,  it  should  reviewed  by  a  contract  specialist.  In  an  ideal 
case,  there  would  be  only  a  few  questions  about  incentives  and  metrics  needed  to  verify 
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and  incentivize  the  perfonnance.  When  the  requirement  is  implemented  into  the  contract, 
it  is  essential  that  the  contractor  has  the  same  interpretation  of  the  stated  requirement  as 
its  developers. 

Apart  from  a  detailed  RFP  and  solicitation,  a  pre-  award  conference  with 
possible  contractors  is  the  best  alternative  to  communicate  the  government’s  needs  to  the 
contractors.  This  could  eliminate  a  lot  of  confusion,  but  requires  detailed  and  professional 
preparation  by  the  government.  The  contractor  must  demonstrate,  in  a  pre-award 
conference,  an  understanding  of  the  complexity,  functional  needs,  and  risks  incorporated 
in  the  requirements.  This  means  they  must  be  given  access  to  critical  information  before 
the  conference  in  order  to  prepare. 

c.  Performance  Control 

There  has  been  a  huge  amount  of  effort  put  into  creating,  wording,  and 
implementing  requirements  into  the  contract;  so  much  that  the  important  step  of  linking 
them  to  the  expected  perfonnance  is  diluted.  Every  requirement  must  be  traceable  to 
measurable  perfonnance  metrics  within  the  program.  The  current  reward  structure  and 
incentives  for  the  contractor  must  directly  relate  to  these  metrics  to  at  least  meet  the 
objectives  as  stated  in  the  contract.  No  fees  or  awards  should  be  paid  for  objectives 
covering  mandatory  items  of  the  contract.  However,  there  must  be  enough  incentives  for 
delivering  superior  quality  and  performance  on  or  ahead  of  schedule.  A  matrix  of 
possible  incentives  is  presented  in  Table  7.  A  current  problem  is  the  lack  of  incentives 
for  a  contractor  to  perform  well  and  deliver  quality  and  capabilities  that  exceed  the 
government  requirements.  This  is  especially  true  for  contracts  that  provide  award  fees  on 
performance  as  stated  in  the  contract.  Every  incentive  given  to  a  contractor  should  be 
based  on  verification  and  non  arbitrary  or  ambiguous  metrics  and  data.  These  incentives 
need  to  adapt  to  the  needs  of  every  single  program,  and  suggest  a  more  suitable  incentive 
structure  than  ones  in  the  past. 
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3.  Acquisition  Process  and  Management 


a.  Funding 

Funding  for  the  Department  of  Defense  is  based  on  four  major  factors: 
percentage  of  GDP,  national  needs  in  other  departments,  security  environment,  and 
requests  from  the  Department  of  Defense.  The  first  recommendation  is  to  reverse  the 
process  of  funding.  Congress  and  the  President  of  the  United  States  must  agree  on  a 
budget  for  the  Department  of  Defense  based  on  the  criteria  above.  Once  the  amount  is 
determined,  the  Secretary  of  Defense  and  the  Joint  Chiefs  of  Staff  should  prioritize 
national  defense  needs  according  to  suggestions  of  the  Services,  based  on  the  insights  of 
their  Combattant  Commanders  for  new  programs  and  their  justification.  Once  this 
priority  list  is  established,  money  should  be  divided  among  programs  suggested  by  the 
Services  in  an  order  governed  by  this  list.  The  President,  Secretary  of  Defense,  Joint 
Chiefs  of  Staff,  and  Service  Chiefs  would  shift  programs  producing  redundant 
capabilities  to  a  specific  Service,  or  they  would  be  cancelled. 

The  Accountability  of  the  Services  would  be  greater,  if  they  were  not 
competing  for  money  directly  from  their  sister  Services,  but  instead  for  a  fair  partial  share 
depending  on  national  security,  joint  and  network  needs,  and  their  unique  capabilities. 
When  the  Services  know  how  much  money  to  expect,  they  can  develop  a  plan  for 
distributing  it  to  programs  that  contribute  the  most  to  national  needs.  Everything  that  is 
not  covered  in  this  plan,  like  inadequate  numbers  of  units  within  a  program  or  smaller 
programs  will  appear  in  a  gap  list.  This  will  identify  the  program,  its  least  operational 
units/sy stems,  how  many  of  those  units  are  desired,  and  how  many  are  covered  by 
funding.  With  these  numbers,  the  Department  of  Defense  could  reach  a  compromise  with 
Congress  over  additional  funding  and  major  contractors  capable  of  providing  the  systems 
according  to  the  budget.  With  this  reversed  flow,  unit  numbers  and  prices  become  much 
more  reliable,  and  planning  by  contractors,  the  Services,  and  Department  of  Defense 
becomes  easier. 

Another  change  should  be  implemented  for  time  effective  appropriation  of 

money.  Money  that  can  not  be  spent  during  final  three  months  should  be  partially 
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recoverable  by  the  Services  if  a  plan  for  the  use  of  this  money  in  the  upcoming  fiscal  year 
for  a  purpose  can  be  provided.  An  incentive  to  save  money  could  definitely  be  reached  at 
a  share  ratio  Treasury/Service  of  30/70  or  above. 

These  recommendations  are  not  easily  achieved.  They  ask  for  a 
considerable  change  of  legal  framework  and  individual  attitude.  Nevertheless,  they  seem 
to  be  worthwhile  in  the  long  run  because  they  address  several  problem  areas:  jealousy 
among  the  Services,  the  influence  of  lobbyists  and  parochial  working  politicians,  and 
dishonesty  in  projections  of  cost  and  schedule. 

b.  Cutting  Edge  Technologies 

New  materials,  technological  breakthroughs,  and  unprecedented 
technological  capabilities  are  fascinating,  but  they  come  at  a  price.  The  research  and 
development  of  new  cutting  edge  technologies  is  costly,  takes  time,  and  bears  the  risk  of 
total  failure  because  of  unexpected  technical  difficulties,  material  problems,  and 
immature  software.  Regardless  of  this,  requirement  requests  for  these  technologies  are 
implemented  in  too  many  major  programs. 

R&D  efforts  before  the  beginning  of  a  program  are  insufficient,  and  there 
are  too  many  immature  components  demanded.  SBIRS  high  is  a  good  example  of  the 
common  mistake  of  rushing  too  early  into  a  program  without  understanding  the  necessary 
background:  complexity,  software  size,  maturity  level  of  components,  and  other 
challenges.  Fascination  with  future  possibilities  impedes  reasonable  and  intensive  risk 
analysis.  Overoptimistic  assumptions  lead  to  decisions  lacking  adequate  standards, 
knowledge  and  wisdom. 

Development  of  those  high  risk  areas  must  be  separated  from  the  program, 
and  be  treated  like  an  upgrade  that,  although  planned  for,  is  not  absolutely  certain.  It  is 
better  to  delay  a  program  an  extra  year  to  clarify  maturity  levels  and  build  realistic 
confidence  in  the  program  than  it  is  to  rush  into  production  without  proper  knowledge. 
The  costs  and  schedule  delays  of  programs  where  immature  technology  was  accepted 
during  CDR  or  production  should  have  taught  this  lesson. 
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Money  must  be  appropriated  before  for  cutting  edge  technology  is 
implemented  into  a  program.  The  Department  of  Defense  can  assist  in  identifying 
promising  technology  to  implement  in  future  programs.  The  defense  industry  can  provide 
information  regarding  the  release  dates  of  these  technologies  with  a  reasonable  monetary 
effort;  this  will  achieve  the  maturity  needed  for  implementation  into  defense  related 
programs.  Industry  and  government  must  be  mutually  patient.  While  one  must  wait  for 
technology  to  mature  before  introducing  into  defense  programs,  the  other  must  wait  to 
earn  the  money  necessary  to  nurture  this  maturity. 

Technology  must  remain  relevant  enough  to  maintain  an  advantage  over 
the  enemy.  Depending  on  the  complexity  of  the  system,  this  can  mean  gathering 
information,  processing  data,  denying  infonnation  and  intelligence,  moving  first,  or 
destroying  targets  while  maintaining  low  vulnerability.  When  the  lives  of  soldiers  are 
involved,  winning  by  only  a  margin  is  certainly  not  desirable. 

Scarce  budget  resources  force  the  consideration  of  cutting  back  on  these 
technologies.  These  technologies  should  not  be  renounced,  but  allowed  the  opportunity 
for  maturity  and  better  performance  after  upgrades.  New  open  architectures  provide  this 
opportunity;  A  vast  number  of  programs  could  prevent  many  problems,  risk,  and 
uncertainty.  We  must  implement  a  better  sanity  check  available  to  the  acquisition 
community  to  decide  whether  cutting  edge  technology  is  mature  enough  to  be 
implemented  into  a  program  or  not.  The  maturity  levels  for  components  alone  does  not 
provide  enough  infonnation  as  it  evaluates  partial  aspects  only  but  does  not  incorporate 
the  integration  and  interface  requirements  of  multiple  components  for  modern  systems- 
of-systems.  The  contractor  can  provide  this  information  if  they  are  not  pressed  to  develop 
cutting  edge  technology  and  their  program  simultaneously,  while  under  considerable 
schedule  pressure. 


c.  Legal  Restrictions 

A  factor  that  that  has  not  been  discussed  yet  is  the  impact  of  current  legal 
restrictions  on  the  acquisition  process  itself.  The  lists  in  Tables  3,  4  and  5  illustrate  the 
amount  of  guidance,  laws  and  regulations  that  apply  to  the  acquisition  process.  For 
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Program  Management  the  AKSS  /DAU  website  list  529  mandatory  documents  that  apply, 
for  Software  Acquisition  Management  alone  60  binding  documents.  It  is  assumed  that 
these  are  intended  to  assist  the  acquisition  workforce.  Unfortunately,  every  major  scandal 
and  unsuccessful  program  was  followed  by  an  outcry  from  Congress  for  more  regulations 
and  guidance  in  the  hope  of  eliminating  the  problem,  but  additional  oversight  adds  to  the 
management  burden  and  may  actually  have  an  opposite  result. 

The  diminished  contracting  workforce  cannot  keep  up  with  updates,  new 
regulations,  and  changing  guidelines.  The  intended  purpose  of  assisting  them  is  missed. 
The  flood  of  regulations,  laws  and  guidance  hampers  their  ability  to  do  their  job.  Many 
laws  and  regulations  apply  to  an  era  of  stable  environments  during  the  Cold  War,  when 
conventional  planning  for  war  and  economies  largely  focused  on  continental  needs.  But 
the  environment  has  changed.  Global  economies  and  interdependencies,  national  and 
social  needs,  regional  conflicts  and  asymmetric  warfare  need  different  planning, 
guidelines  and  laws  to  guide  the  way. 

Global  interdependencies  drive  the  first  recommendation.  It  is  time  to 
share  responsibilities  and  privileges  equally  among  allies.  The  demand  for  more 
adjustment,  consultation,  and  combined  effort  is  essential  for  addressing  global 
challenges  and  threats  in  the  near  and  long  term  future.  National  protection  of  defense 
contractors  is  a  limiting  factor  to  competition  and  a  waste  of  resources.  Like  sharing 
capabilities  within  the  Services,  allies  have  to  share  their  defense  industry  capabilities  to 
allow  competition,  better  pricing,  and  quality  warfighting  capabilities. 

The  U.S.  is  no  exception.  The  Buy  American  Act  is  a  legacy  that  does  not 
fit  a  global  economies  and  defense  efforts  perspective.  Sharing  technologies  among  allies 
reduces  procurement  cost  and  produces  innovation  and  higher  levels  of  standardization. 
The  security  issue  within  this  approach  can  be  solved  with  a  similar  approach  to  the  one 
discussed  in  the  section  about  software  security  and  maintenance.  The  impact  on  the 
defense  industry  would  be  more  competition,  and  the  danger  for  national  workplaces 
could  be  minimized  by  arrangements  where  the  systems  are  actually  produced.  Opening 
up  national  restrictions  will  allow  a  broader  base  of  expertise  and  production. 

Cooperation  in  developing  future  systems  will  also  stabilize. (See  page  13) 

44 


d.  Acquisition  Flexibility 


Change  in  the  acquisition  environment  calls  for  a  variety  of  acquisition 
tools  and  processes.  Some  of  the  new  procurement  methods  are  evident  in  the  area  of 
contingency  contracting.  This  type  of  procurement  will  be  a  part  of  fast  responses  to 
imminent  needs  in  the  future,  especially  during  times  of  war.  Lessons  learned  from  recent 
years  are  applied,  like  the  need  for  more  continuous  oversight  and  clearly  expressed 
requirements,  are  useful  for  satisfying  urgent  needs. 

FAR  part  13.546  contains  an  opportunity  for  easing  the  acquisition  process 
for  commercial  item  acquisition  that  is  widely  not  applied.  This  particular  section  of  the 
FAR  is  dedicated  to  easy  acquisition  procedures  and  save  transaction  costs  to  reduce  the 
workload  for  the  acquisition  and  contracting  workforce.  This  section’s  implications,  as 
intended  by  Congress,  are  not  commonly  known  or  practiced.  This  section  can  save  the 
Services  approximately  $9300  per  transaction47  and  significantly  reduce  the  workload. 
Last  year  alone,  the  Navy  alone  had  60,000  transactions  that  would  have  qualified  under 
this  section48.  A  simple  clarification  and  reminder  to  all  contracting  specialists  could 
reduce  their  workload  and  initiate  instant  savings. 

To  use  the  latest  improvements  to  diminish  legal  restrictions  for 
procurement  efforts  and  enhance  acquisition  flexibility  like  the  Federal  Acquisition 
Reform  Act  (FARA),  Federal  Acquisition  Streamlining  Act  (FASA)  and  Service 
Acquisition  Reform  Act  (SARA)  are  additional  opportunities  to  booster  commercial  item 
acquisition  and  competition.. 

Global  changes,  different  war  environments  and  smaller  armed  services 
have  created  another  challenge  that  requires  focus  and  oversight.  About  60%  of  the 
acquisition  budget  has  already  been  spent  on  services,  most  of  which  are  outsourced  to 
civilian  contractors.  So  much  money  is  involved  that  promises  made  by  the  contractors 


4(1  See  also  FAR,  part  13  Simplified  Acquisition  Procedures,  subpart  13.5  Test  Program  for  Certain 
Commercial  Items. 

47  According  to  comments  in  MN3304  contacting  class,  Yoder  Cory. 

48  According  to  comments  in  MN3304  contracting  class,  Yoder  Cory. 
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and  random  controls  are  not  reliable.  There  is  a  need  for  a  workforce  large  enough  for 
constant  oversight  over  performance,  progress  of  the  contract,  and  clear  metrics  for 
evaluation  of  their  performance.  Many  complaints  about  lost  money  during  contingency 
contracting  and  service  contracts  implicate  the  lack  of  availability  and  responsibility  for 
oversight  and  follow  up  of  the  project  or  service.  Evaluations  based  simply  on  the 
completion  of  a  project  are  arbitrary,  and  do  not  achieve  the  best  results  possible  based  on 
the  money  used. 

Early  service  pioneers  like  postal  services,  catering  agencies,  warehouses, 
construction  businesses  and  maintenance  branches  provide  great  models  for  the 
evaluation  criteria  that  will  allow  a  better  determination  of  contractor  perfonnances. 
Combined  with  realistic  requirement  descriptions,  these  criteria  will  produce  better 
results  from  outsourced  services. 

K.  SUMMARY 

The  present  difficulties  in  the  acquisition  process  do  not  mean  it  is  a  broken 
system.  Many  aspects  of  the  acquisition  process  have  improved  over  time  because  of 
many  adjustments  made  and  lessons  that  have  been  incorporated  into  the  best  practices 
and  regulations.  There  are  deficiencies  that  must  be  addressed,  but  this  is  not  an 
uncommon  occurrence  for  complex  organizations  and  processes.  Sometimes  the 
acquisition  and  contracting  community  is  held  responsible  for  inefficiencies,  bad 
judgements  and  political  decisions.  They  knew  the  decisions  were  wrong  as  far  as  the 
efficiency  of  the  acquisition  process  was  concerned,  but  could  not  prevent  those 
decisions.  As  a  consequence  they  suffered  from  those  decisions  made  at  a  level  out  of 
their  range  of  control,  to  be  made  and  suffered  from  the  consequences  of  those  decisions 
out  of  their  range  of  control.  This  should  a  frustration;  there  was  no  way  to  avoid  this 
from  happening,  which  is  proof  of  the  need  for  change  and  optimization  in  these 
processes.  As  economics,  political  and  social  environments,  global  challenges  and  war 
change,  processes,  regulations  and  laws  need  to  adapt  accordingly.  It  is  impossible  to 
keep  up  because  the  acquisition  process  cannot  change  over  night,  and  requirements 
rapidly  change  as  experienced  in  recent  years.  The  acquisition  process  is  adaptive.  As  the 
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best  practices  and  learning  are  applied  to  current  acquisition  processes,  they  become 
more  reliable.  They  will  become  even  more  reliable  as  more  of  the  budget  is  spent  on 
commercial  services,  which  are  easier  to  apply  than  cutting  edge  software,  hardware,  and 
program  development.  The  identification  of  software  and  hardware-requirements,  and 
their  alignment  with  the  different  processes  will  always  be  crucial.  This  allows  new 
systems  within  the  right  framework  begin,  as  well  as  save  money,  allow  quick 
procurement,  and  deliver  the  highest  quality  available  to  warfighters. 

L.  FUTURE  RESEARCH 

Future  research  is  needed  in  the  problem  areas  mentioned  that  but  not  explicitly 
covered.  The  most  interesting  fields  at  this  point  are: 

1 .  Behaviour  of  the  DoD  acquisition  process  regarding  resistance  to  change 
in  policy  and  change49. 

2.  The  willingness  off  political  forces  to  align  budgeting  with  the  needs  of 
the  acquisition  process. 

3.  The  influence  of  changes  in  the  acquisition  process  moving  towards  a  joint 
acquisition  authority,  rather  than  the  sole  responsibility  of  the  services  for 
“their”  programs. 

4.  The  impact  of  an  increasing  amount  of  the  defense  budget  for  use  on 
contractor  services,  and  the  government’s  ability  to  require  new  systems 
and  modernize  equipment. 

5.  How  building  strategic  partnerships  with  contractors  can  reduce 
contracting  regulations  and  save  costs. 


49  See  also  Business  Dynamics,  Systems  Thinking  and  Modeling  for  a  Complex  World,  Sterman  John 
D.,  p.  10,  Chapter  1.1.2. 
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process 


Exerpts  from  laws,  regulations  and  guideline  documents  for  the  acquisition 
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Table  3.  Federal  Law 


2006  Quadrennial  Defense  Review  (QDR)  Strategic  Communication  (SC)  Execution  Roadmap 

Bid  Protests  at  GAO:  A  Descriptive  Guide  Sixth  Edition 

Changes  to  Process  Standards  Canceled  Without  Replacement  on  Existing  Contracts  Under  the 
Single  Process  Initiative 

DoC  Guide  on  Section  845/804  Other  Transactions  OTs  for  Prototype  Projects 

DoD  Evaluating  the  Price  of  Commercial  Items  in  a  Sole-Source  Environmentlnformation 
GuideVolume  2 

DOL  Employment  Law  Guide 

DOL  Federal  Contract  Compliance  Manual 

E-Authentication  Guidance  for  Federal  Agencies 

EX.  ORD  12995,  Amendment  to  EX.  ORD.  NO.  12873;  Federal  Acquisition,  Recycling,  and  Waste 
Prevention 

EX.  ORD  NO.  13148;  Greening  the  Government  through  Leadership  in  Environmental  Management 

EX.  ORD.  NO. 11514;  Protection  and  Enhancement  of  Environmental  Quality 

EX.  ORD.  NO.  121 14;  Environmental  Effects  Abroad  of  Major  Federal  Actions 

EX.  ORD.  NO. 12196;  Occupational  Safety  and  Health  Programs  for  Federal  Employees 

EX.  ORD.  NO. 12591  Facilitating  Access  to  Science  and  Technology 

EX.  ORD.  NO. 12770;  Metric  Usage  in  Federal  Government  Programs 

EX.  ORD.  NO. 12829  National  Industrial  Security  Program 

EX.  ORD.  NO.  12856;  Federal  Compliance  with  Right-to-Know  Laws  and  Pollution  Prevention 
Requirements 

EX.  ORD.  NO. 12885;  Amendment  To  Executive  Order  No. 12829 

EX.  ORD.  NO. 12958  Classified  National  Security  Information 

EX.  ORD.  NO.  12968  Access  to  Classified  Information 

EX.  ORD.  NO. 13010  Critical  Infrastructure  Protection 

EX.  ORD.  NO. 13025;  Amendment  to  EO  13010;  Presidents  Commission  on  Critical  Infrastructure 
Protection 

EX.  ORD.  NO.  13026;  Administration  of  Export  Controls  on  Encryption  Products 

EX.  ORD.  NO. 13041  Further  Amendment  to  Executive  Order  13010 

EX.  ORD.  NO. 13064  Further  Amendment  to  Executive  Order  13010;  Critical  Infrastructure 
Protection 

EX.  ORDER  NO.  13392;  Improving  Agency  Disclosure  of  Information 

Ex.Ord.  13423  Strenghening  Federal  Environmental,  Energy,  and  Transporation  Management 

Executive  Order:  Providing  Opportunities  for  Service-Disabled  Veteran  Businesses  to  Increase  Their 
Federal  Contracting  and  Subcontracting 

Executive  Order:  Strengthening  Federal  Environmental,  Energy,  and  Transportation  Management 

Export  Administration  Regulations  Database 

Field  Manual  (FM)  3-100.21  (formerly  FM  200-21),  Contractors  on  the  Battlefield 

GSA  Acquisition  Letter  V  04-05:  Purchases  on  Behalf  of  Other  Agencies 

Industrial  Security  Letter  ISL  2006-02 

Instructions  for  Modular  Open  Systems  Approach  (MOSA)  Implementation;  USD  (AT&L)  Memo 

MARCOR  Project  Officers  Certification  and  Accreditation  Handbook  E.  Certification  Analysis 
Requirements 

MARCOR  Systems  Cost  Analysis  Handbook  E.  Life  Cycle  Cost  Estimate  (LCCE)  Example 

MARCOR  Systems  Cost  Analysis  Handbook  II.  Users  Manual,  Summary  Version  Life  Cycle  Cost 
Model  (SVLCCM), Version  3.2 

NAVSUP  P-505  Preparing  Hazardous  Materials  for  Military  Air  Shipments 

50  See  also  https://akss.dau.mil/Lists/Policy/Documents/  for  more  information. 
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Federal  Law  (continued) 


OFPP  Memorandum,  "Directly  Interested  Party"  Clarification  Memo 

OFPP  Memorandum,  2005  Alternative  Dispute  Resolution  Awards  in  Acquisition 

OFPP  Memorandum,  Agency  Requirement  for  a  plan  to  Transition  to  the  Federal  Procurement  Data 
System  (FPDS) 

OFPP  Memorandum,  Avoiding  Duplication  of  Agency  Activities  with  the  Presidential  E-Government 
and  Lines  of  Business  Initiatives 

OFPP  Memorandum,  Buy  American  Reporting  Requirement 

OFPP  Memorandum,  Buying  Accessible  Electronic  and  Information  Technology  and  Complying  with 
Section  508  of  the  Rehabilitation  Act 

OFPP  Memorandum,  Contractor  Responsibility  Determinations  and  Indefinite-Delivery  Contracts 

OFPP  Memorandum,  Developing  the  Acquisition  Management  Skills  of  the  Architectural  and 
Engineering  Workforce 

OFPP  Memorandum,  Development  of  "Green"  Plans  for  Competetive  Sourcing 

OFPP  Memorandum,  Establishment  of  Interagency  Acquisition  Working  Group 

OFPP  Memorandum,  Federal  Acquisition  Institute  Board  of  Directors  Charter 

OFPP  Memorandum,  Implementing  Management  Controls  to  Support  Increased  Micro-purchase 
Threshold  for  Hurricane  Katrina  Rescue  and  Relief  Operations 

OFPP  Memorandum,  Implementing  Strateqic  Sourcinq 

OFPP  Memorandum,  Limitation  on  Use  of  Special  Micro-purchase  Threshold  Authority  for  Hurricane 
Katrina  Rescue  and  Relief  Operations 

OFPP  Memorandum,  M-02-05,  Use  of  Government  Purchase  and  Travel  Cards 

OFPP  Memorandum,  M-04-12,  Performance  Periods  in  Public-Private  Competitions 

OFPP  Memorandum,  M-05-01,  Report  to  Congress  on  FY  2004  Competitive  Soourcing  Efforts 

OFPP  Memorandum,  M-06-01,  Report  to  Congress  on  FY  2005  Competitive  Sourcing  Efforts 

OFPP  Memorandum,  Publication  of  Brand  Name  Justifications 

OFPP  Memorandum,  Recession  of  Monthly  Reporting  on  Electronic  Commerce  Statistics  to  the 
General  Services  Administration 

OFPP  Memorandum,  Report  on  Competitive  Sourcinq  Results,  Fiscal  Year  2004 

OFPP  Memorandum,  Request  Contracting  Information  on  Contractors  Operating  in  Iraq 

OFPP  Memorandum,  Revised  FAR  Process 

OFPP  Memorandum,  The  Federal  Acquisition  Certification  in  Contracting  Program 

OFPP  Memorandum,  The  Presidents  Welfare  to  Work  Program 

OFPP  Memorandum,  Update  on  the  Electronic  Subcontracting  Reporting  System 

OFPP  Memorandum,  Utilization  of  Commercially  Available  Online  Procurement  Services 

OFPP  Policy  Letter  05-01,  Developing  and  Managing  the  Acquisition  Workforce 

OFPP  Policy  Letter  80-1;  Section  211  of  Public  Law  95-507,  Subcontracting:  Agency  Coordination 
with  the  Small  Business  Administration  Resident  Procurement  Center  Representatives 

OFPP  Policy  Letter  80-2,  Supp  1;  Requlatory  Guidance  on  Section  211;  of  Public  Law  95-507 

OFPP  Policy  Letter  80-4;  Womens  Business  Enterprise  Program 

OFPP  Policy  Letter  91-3;  Reporting  Nonconforming  Products 

OFPP  Policy  Letter  92-1;  Inherently  Governmental  Functions 

OFPP  Policy  Letter  92-4;  Procurement  of  Environmentally-Sound  and  Energy-Efficient  Products  and 
Services 

OFPP  Policy  Letter  93-1  (Reissued);  Management  Oversight  of  Service  Contracting 

OFPP  Policy  Letter  99-1,  Small  Business  Procurement  Goals 

OMB  Circular  A-l;  Bureau  of  the  Budgets  System  of  Circulars  and  Bulletins  to  Executive 
Departments  and  Establishments;  Revised 

OMB  Circular  A-102;  Grants  and  Cooperative  Agreements  With  State  and  Local  Governments; 
Revised 

OMB  Circular  A-109;  Major  Systems  Acquisitions 

OMB  Circular  A-ll;  Preparing  and  Submitting  Budget  Estimates 

OMB  Circular  A-110;  Uniform  Administrative  Requirements  for  Grants  and  Agreements  With 
Institutions  of  Higher  Education,  Hospitals,...; 

OMB  Circular  A-122;  Cost  Principles  for  Nonprofit  Organizations 
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Federal  Law  (continued) 


OMB  Circular  A-123;  Management  Accountability  and  Control 

OMB  Circular  A-126;  Improving  the  Management  and  Use  of  Government  Aircraft;  (Revised) 

OMB  Circular  A-127;  Financial  Management  Systems;  Revised  —  Transmittal  Letter  2 

OMB  Circular  A-129;  Policies  for  Federal  Credit  Programs  and  Non-Tax  Receivables 

OMB  Circular  A-130  Management  of  Federal  Information  Resources 

OMB  Circular  A-131;  Value  Engineering 

OMB  Circular  A-133;  Audits  of  States,  Local  Governments,  and  Non-Profit  Institutions 

OMB  Circular  A-134;  Financial  Accounting  Principles  and  Standards 

OMB  Circular  A-135;  Management  of  Federal  Advisory  Committees 

OMB  Circular  A-136,  Financial  Reporting  Reguirements 

OMB  Circular  A-16;  Coordination  of  Surveying,  Mapping,  and  Related  Spatial  Data  Activities; 
Revised 

OMB  Circular  A-19;  Legislative  Coordination  and  Clearance;  Revised 

OMB  Circular  A-21;  Cost  Principles  for  Educational  Institutions 

OMB  Circular  A-25;  User  Charges;  Revised  —  (Transmittal  Memorandum  No.l) 

OMB  Circular  A-34;  Instruction  on  Budget  (Superceded  by  OMB  Circular  A-ll,  Part  4)  Execution 

OMB  Circular  A-45;  Rental  and  Construction  of  Government  Quarters;  (Revised) 

OMB  Circular  A-50;  Audit  Followup;  Revised 

OMB  Circular  A-76 

OMB  Circular  A-76  (Revised)  Transmittal  Memorandum  No. 22;  Performance  of  Commercial 
Activities 

OMB  Circular  A-76;  Revised  Supplemental  Handbook;  Performance  of  Commercial  Activities 

OMB  Circular  A-76;  Transmittal  Memorandum  No. 20;  Implementation  of  the  Federal  Activities 
Inventory  Reform  Act  of  1998  (Public  Law  105-270)  (FAIR  Act) 

OMB  Circular  A-87;  Cost  Principles  for  State,  Local  and  Indian  Tribal  Governments;  Revised 

OMB  Circular  A-89;  Federal  Domestic  Assistance  Program  Information;  Revised 

OMB  Circular  A-94;  Guidelines  and  Discount  Rates  for  Benefit-Cost  Analysis  of  Federal  Programs; 
Revised 

OMB  Circular  A-97;  Rules  and  Regulations  Permitting  Federal  Agencies  to  Provide  Specialized  or 
Technical  Services  to  State  and  Local  Units  of  Government  Under  Title  III  of  the  Intergovernmental 

OMB  M-3-14,  Reducing  Cost  and  Improving  Quality  in  Federal  Purchases  of  Software 

OMB  Memorandum  04-07,  Report  to  Congress  on  FY  2003  Competitive  Sourcing  Efforts 

OMB  Memorandum  M-00-07  Incorporating  and  Funding  Security  in  Information  Systems 
Investments 

OMB  Memorandum;  Compensation  Benchmark  Amount  Pursuant  to  Section  808  of  Public  Law  105- 
85 

OMB  Privacy  Policies  and  Data  Collection  on  DoD  Public  Web  Sites 

Presidential  Policy  on  Offsets  in  Military  Export 

Protests,  Claims,  and  Alternative  Dispute  Resolution  (ADR)  as  Factors  in  Past  Performance  and 
Source  Selection  Decisions 

SECNAVINST  5510. 36A  DEPARTMENT  OF  THE  NAVY  (DON)  INFORMATION  SECURITY  PROGRAM 
(ISP)  INSTRUCTION 

Technology  Protection  —  ProgramManagement  Education 

United  States  Code 

50 


Table  4.  Statutory  Laws 


2006  Quadrennial  Defense  Review  (QDR)  Strategic  Communication  (SC)  Execution  Roadmap 

Clean  Air  Act,  42  U.S.C.  s/s  7401  (1970) 

Clean  Water  Act 

Clinger-Cohen  Act  of  1996 

Comprehensive  Environmental  Response,  Compensation,  and  Liability  Act  (Superfund),  42  U.S.C. 
s/s  9601,  (1980) 

DoD  4500. 9-R  Defense  Transportation  Regulation,  Pt  II,  Cargo  Movement,  Attachment  V7,  FMS 
Shipments 

Emergency  Planning  &  Community  Right  to  Know  Act,  42  U.S.C.  11001 

Endangered  Species  Act,  7  U.S.C.  136;  16  U.S.C.  460,  (1973) 

Environmental  Impact  Analysis  Process  (EIAP),  32  CFR  989 

Federal  Acquisition  Reform  Act  (FARA)  of  1996 

Federal  Acquisition  Streamlining  Act  (FASA) 

Federal  Information  Security  Management  Act 

Freedom  of  Information  Act,  5  U.S.C.  s/s  552  (1996) 

Marine  Protection,  Research,  and  Sanctuaries  Act,  33  USC  1401,  (1972) 

Military  Munitions  Rule,  42  U.S.C.  s/s  300f,  (1974) 

National  Environmental  Policy  Act,  42  USC,  Sections  4321  thru  4347 

Noise  Control  Act,  42  USC  4901 ,  (1 996) 

Occupational  Safety  and  Health  Act,  29  U.S.C.  651,  (1970) 

Oil  Pollution  Act,  33  U.S.C.  2702  to  2761 

P.  L.  107-347  U.  S.  Code  44  Ch  36,  E-Government  Act  of  2002 

P.  L.  108-375  SEC.  81 1 .  RAPID  ACQUISITION  AUTHORITY  TO  RESPOND  TO  COMBAT  EMERGENCIES. 

P.L.  100-235  --  (H.R.  145);  Computer  Security  Act  of  1987 

P.L.  100-533  --  (H.R.  5050);  Womens  Business  Ownership  Act  of  1988 

P.L.  104-106;  National  Defense  Authorization  Act  for  Fiscal  Year  1996 

P.L.  104-13;  Paperwork  Reduction  Act  of  1995 

P.L.  104-164  -  (H.R.  3121);  Defense  and  Security  Assistance  Improvements 

P.L.  104-320;  The  Administrative  Dispute  Resolution  Act  of  1996 

P.L.  106-79;  Department  of  Defense  Appropriations  Act,  2000  (Excepts) 

P.L.  107-314;  Bob  Stump  National  Defense  Authorization  Act  for  Fiscal  Year  2003 

P.L.  97-255  -  (H.R.  1526);  Federal  Managers  Financial  Integrity  Act  of  1982 

Pollution  Prevention  Act  1990,  42  U.S.C.  13101  and  13102,  (1990) 

Privacy  Act  of  1974  5  U.S.C.  A§  552a 

Resource  Conservation  &  Recovery  Act  (RCRA),  42  U.S.C.  s/s  6901,  (1976) 

Section  8088,  Public  Law  107-248  Registering  Financial  Management  Information  Technology  Systems  with  DoD 
Chief  Information  Officer 

Section  8102  DoD  Appropriations  Act. doc,  P.L.  106-259,  Section  8102  (DoD  Appropriations  Act,  2001 ) 

Services  Acquisition  Reform  Act  (SARA)  of  2003. 

Title  10,  Part  II,  Chapter  87,  Section  1702USD/AT&L  Authorities  and  Reponsibilities 

Title  10,  Part  II,  Chapter  87,  Section  1703Director  of  Acquisition  Education,  Training,  and  Career  Development 

Title  10,  Part  II,  Chapter  87,  Section  1704:Service  acquisition  executives:  authorities  and  responsibilities 

Title  10,  Part  II,  Chapter  87,  Section  1721  :Designation  of  Acquisition  Positions 

Title  10,  Part  II,  Chapter  87,  Section  1723:General  education,  training,  and  experience  requirements 

Title  10,  Part  II,  Chapter  87,  Section  1724:Contracting  positions  qualification  requirements 

Title  10,  Part  II,  Chapter  87,  Section  1725:Office  of  Personnel  Management  Approval 

Title  10,  Part  II,  Chapter  87,  Section  1731  :Acquisition  Corps  in  General. 

Title  10,  Part  II,  Chapter  87,  Section  1732:Selection  Criteria  and  Procedures 

Title  10,  Part  II,  Chapter  87,  Section  1733:Critical  Acquisition  Positions 

Title  10,  Part  II,  Chapter  87,  Section  1734:Career  Development 

Title  10,  Part  II,  Chapter  87,  Section  1735:Education,  training,  and  experience  requirements  for  critical  acquisition 
positions 

Title  10,  Part  II,  Chapter  87,  Section  1737:Definitions  and  General  Provisions 

Title  10,  Part  II,  Chapter  87,  Section  1741  Policies  and  programs:  establishment  and  implementation 

Title  10,  Part  II,  Chapter  87,  Section  1742:lntem  Program 
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Statutory  Laws  (continued) 


Title  10,  Part  II,  Chapter  87,  Section  1745:Additional  education  and  training  programs  available  to  acquisition 
personnel 

Title  10,  Part  II,  Chapter  87,  Section  1746:Defense  acquisition  university  structure 

Title  10,  Part  II,  Chapter  87,  Section  1761  :Management  Information  Systems 

Title  10,  Part  II,  Chpater87,  Section  1701,  Management  Policies 

Title  10,  Part  II,  Chpater  87,  Section  1764,  Repealed 

Title  10,  Part  IV,  Chapter  146,  Section  2460:  Definition  of  depot-level  maintenance  and  repair 

Title  10,  Section  139,  U.S.C.,  Director  of  Test  and  Evaluation 

Title  10,  Section  2302,  U.S.  Code,  Definitions 

Title  10,  Section  2302d,  U.S. Code  -  Major  system:  definitional  threshold  amounts 

Title  10,  Section  2341,  U.S.C.,  Authority  to  acquire  logistic  support,  supplies,  and  services  for  elements  of  the 
armed  forces  deployed  outside  the  United  States 

Title  10,  Section  2342,  U.S.C.,  Cross-servicing  agreements 

Title  10,  Section  2350a,  U.S.C., Cooperative  Research  and  Development  Projects:  Allied  Countries 

Title  10,  Section  2364,  U.S.C.,  Coordination  and  Communication  of  Defense  Research  Activities 

Title  10,  Section  2366,  U.S.C.,  Major  Systems  and  Munitions  Programs:  Survivability  and  Lethality  Testing 
Required  Before  Full-scale  Production 

Title  10,  Section  2377,  U.S.C.,  Preference  for  Acquisition  of  Commercial  Items 

Title  10,  Section  2399,  U.S.C.,  Operational  Test  and  Evaluation  of  Defense  Acquisition  Programs 

Title  10,  Section  2400,  U.S.C.,  Low-rate  Initial  Production  of  New  Systems 

Title  10,  Section  2430,  U.S.C.,  Major  Defense  Acquisition  Program  Defined 

Title  10,  Section  2432,  U.S.C.,  Selected  Acquisition  Reports 

Title  10,  Section  2433,  U.S.C.,  Unit  Cost  Reports 

Title  10,  Section  2434,  U.S.C.,  Independent  Cost  Estimates;  Operational  Manpower  Requirements 

Title  10,  Section  2435,  U.S.C.,  Baseline  Description 

Title  10,  Section  2440,  U.S.C.,  Technology  and  Industrial  Base  Plans 

Title  10,  Section  2464,  U.S.C.,  Core  Logistics  Functions 

Title  10,  Section  2466,  U.S.C.,  Limitations  on  the  Performance  of  Depot-Level  Maintenance  of  Material 

Title  10,  Section  2469,  U.S.C.,  Contracts  to  Perform  Workloads  Previously  Performed  by  Depot-Level  Activities  of 
the  Department  of  Defense;  Requirement  of  Competition 

Title  10,  Section  2531,  U.S.C.,  Defense  memoranda  of  understanding  and  related  agreements 

Title  10,  Section  II,  Chapter  87,  Section  1722:Career  Development 

Title  10,  U.S.  Military  Forces  Military  Law 

Title  10.  Section  II,  Chapter  87,  Section  1705:Directors  of  Acquisition  Career  Management  in  the  military 
departments 

Title  15,  Section  644,  U.S.  Code,  Awards  or  Contracts 

Title  22,  Section  2751,  U.S.C.,  Need  for  international  defense  cooperation  and  military  export  controls; 
Presidential  waiver;  report  to  Congress;  arms  sales  policy 

Title  44,  Chapter  31 ,  Records  Management  by  Federal  Agencies 

Title  47,  Section  305,  U.S.C.,  Government-Owned  Stations 

Title  47,  Section  901,  U.S.C.,  Definitions;  findings;  policy  (National  Telecommunications  &  Information 
Administration 

Title  47,  Section  902,  Establishment;  assignment  functions  (National  Telecon  &  Information  Administrtion) 

Title  47,  Section  903,  U.S.C.,  Spectrum  management  activities,  (National  Telecommunications  &  Information 
Administration) 

Title  47,  Section  904,  U.S.C.,  General  administrative  provisions 

Title  5,  Section  306,  U.S.C.,  Strategic  Plans  (part  of  the  Government  Performance  and  Results  Act) 

U.S.  Code  10,  Chapter  131,  Sec.  2220.  -  Performance  based  management:  acquisition  programs 
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Table  5.  Federal  Acquisition  Regulation  (Supplements) 


AFARS  Part  5123,  Environment,  Conservation,  Occupational  Safety,  and  Drug-Free  Workplace 

AFARS  Part  5125,  Foreign  Acquisition 

AFFARS  —  Part  5325;  Foreign  Acquisition;  AFAC  96-2 

AFMCFARS  —  Part  5325;  Foreign  Acquisition 

Air  Combat  Command  FAR  Supplement  (ACCFARS) 

Air  Education  &  Training  Command  FAR  Supplement  (AETCFARS) 

Air  Force  FAR  Supplement  (AFFARS) 

Air  Force  Materiel  Command  FAR  Supplement  (AFMCFARS) 

Air  Force  Reserve  Command  FAR  Supplement  (AFRC) 

Air  Force  Space  Command  FAR  Supplement  (AFSPCFARS) 

Air  Mobility  Command  FAR  Supplement  (AMCFARS) 

Army  Federal  Acquisition  Regulation  Manual  No.  2  (Contingency  Contracting) 

Army  Federal  Acquisition  Regulation  Supplement  (AFARS) 

Defense  Federal  Acquisition  Regulation  Supplement,  Procedures,  Guidance  &  Information  (DFARS  PGI) 

Department  of  Energy  FAR  Supplement  (DEARS) 

Environmental  Protection  Agency  Acquisition  Regulation  (EPAAR) 

FORSCOM  FAR  Supplements 

General  Services  Administration  Acquisition  Manual  (GSAM) 

MARCOR  Systems  Cost  Analysis  Handbook  D.15.  Material  Consumption 

National  Aeronautics  and  Space  Administration  FAR  Supplement  (NFS) 

National  Guard  FAR  Supplement  (NGFARS) 

Navy  Marine  Corps  Acquisition  Regulation  Supplement(NMCARS) 

NMCARS  Part  5225;  Foreign  Acquisition;  Through  Change  97-15 

Performance-Based  Service  Acquisition  (PBSA) 

U.S.  Army  Corps  of  Engineers  FAR  Supplement  (EFARS) 

U.S.  Special  Operations  Command  FAR  Supplement  (SOFARS) 
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Table  6.  Helpful  tools  for  developing  software51 


Aircraft  Sustainability  Model 
(ASM  7) 

Air  Force 

AFMC 

AF  spec  to  Action 
Officers 

Pre- Award  Information 

Exchange  System  (PIXS  5.0) 

Air  Force 

ASC/SYG 

SEER-Hardware  Estimation 
Model  (SEER-H) 

Air  Force 

ASC/FMCE 

Formal  Risk  Analysis  (FRISK 
4.00) 

Air  Force 

SMC/FMC 

COTS- 

Aerospace  Corp 

Cost  Management 

PRICE  TruePlanning 

Air  Force 

ASC/FMCE 

Price  Estimating  - 
Contracting 

Process  Analysis  and  Project 
Integrated  Environment 

Air  Force 

SMC/Det  11 

Project  Management 

Data  Item  Descriptions  Advisor 

Air  Force 

AFMC 

Requirements 

Cost/Risk  Identification  & 
Management  System  (CRIMS 

Air  Force  SAF/AQXR  Send 
Email 

Air  Force 

SAF/AQXR 

Risk  Assessment 

Security  Information 

Management  System  (SIMS) 

Air  Force 

AFML/COTS- 
SIMS  Software 

Security  Management 

Applied  Computational  Fluid 
Dynamics  (ACFD) 

Air  Force 

Eglin  Air  Force 
Base 

Modeling  Sim 

AFTOC  Management 

Information  System 

Air  Force 

SAF/AFCAA 

Total  Ownership  Cost 

Risk  AoA  (Predictive  Risk 
Analysis  for  the  AoA  process) 

Air  Force 

AFMC 

Cost  Analysis;  Project 
Management;  Risk 
Assessment 

51  See  also  AT&L  Knowledge  Sharing  System  https://akss.dau.mil/default.aspx. 
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Table  7.  Incentives  to  boost  contractor  performance 


Incentive 

Based  on* 

Share  of  cost  savings  at  a  certain  rate 

Cost  savings  for  the  government 

Additional  profit  /  increased  production 
numbers  /  strategic  partnership  with  long 
term  contracts 

Enhanced  mission  capabilities  in  the  stated 
operational  environment  due  to  exceeded 
government  requirements 

Additional  profit  or  increased  production 
numbers 

Design  for  easy  ubgradeability/ 
interoperability 

Additional  profit 

Better  quality  and  increased  MTBF,  AoA 

Additional  profit 

Better  maintenance  support  over  an  extended 
life-cycle 

Additional  profit 

Low  amount  of  software  maintenance 
needed 

Additional  profit 

Low  amount  of  maintenance  needed 

Additional  profit 

Low  amount  of  training  needed 

*the  different  sections  have  to  be  supported  by  clear  metrics  to  justify  being  eligible  for 
an  increased  amount  of  profit  or  other  benefit. 


55 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


56 


LIST  OF  REFERENCES 


Apte,  Aruna.  (2006).  Spiral  Development:  A  perspective.NPS-GSBPP-05-009. 

Banus,  Stephen  P.  (1997).  Financing  contingency  operations  in  the  new  strategic 

environment:  are  we  properly  matching  resources  with  mission  requirements? 

Blanchard,  Benjamin  S.  (2006).  Systems  Engineering  and  Analysis. 

Coon,  Edith-Dawn.  (2006).  Analyzing  the  structure  of  Airforce  Space  acquisitions 

(electronic  resource).  Financing  contingency  operations  in  the  new  strategic  are 
we  properly  matching  resources  with  mission  requirements?  AD-A333  329. 

Cysneiros,  L.  M.,  &  Leite,  Julio  Cesar  Sampaio  do  Prado.  (2004).  Nonfunctional 
requirements:  From  elicitation  to  conceptual  models.  IEEE  Transactions  on 
Software  Engineering,  30(5),  328. 

Fallin,  H.  K.,  Jr,  &  Schmidt,  W.  H.  P.  (2000).  Allied  technology  requirements  call  for 
streamlining  acquisition.  Signal,  54(10),  78. 

Forrester,  Eileen.  (2006).  A  process  research  framework:  the  International  Process 
Research  Consortium  ISBN  9780978695613. 

Garrett,  Gregory.  A.  &  Rendon,  Rene  G.  (2006).  U.S.  military  program  management: 
lessons  learned  and  best  practices.  Management  Concepts,  Vienna. 

Hagge,  L.,  &  Lappe,  K.  (2005).  Sharing  requirements  engineering  experience  using 
patterns.  IEEE  Software,  22(1),  24. 

Lang,  M.,  &  Fitzgerald,  B.  (2005).  Hypermedia  systems  development  practices:  A 
survey. 

Maiden,  N.  (2006).  Improve  your  requirements:  Quantify  them.  IEEE  Software,  23(6), 

68. 

Maiden,  N.  (2006).  Servicing  your  requirements.  IEEE  Software,  23(5),  14. 

Maiden,  N.,  Gizikis,  A.,  &  Robertson,  S.  (2004).  Provoking  creativity:  Imagine  what 
your  requirements  could  be  like.  IEEE  Software,  21(5),  68. 

McKinney,  Steven  P.  (2006).  Analysis  of  Naval  NETWAR  FORCEnet  Enterprise 
[electronic  resource]:  Implications  for  capabilities  based  budgeting. 

Menzies,  T.,  &  Richardson,  J.  (2006).  Making  sense  of  requirements,  sooner.  Computer, 
39(10),  112. 


57 


Naegle,  Brad.  (2006).  Developing  software  requirements  supporting  open  architecture 
performance  goals  in  critical  DoD  System-of-systems  [electronic  resource]. 
Analysis  of  Naval  NETWAR  FORCEnet  Enterprise  [electronic  resource]  :NPS- 
GSBPP-06-012. 

Orr,  K.  (2004).  Agile  requirements:  Opportunity  or  oxymoron?  IEEE  Software,  21(3),  71. 

Rendon,  Rene.  (2006).  Using  a  modular  open  systems  approach  in  Defense  Acquisitions: 
implications  for  the  contracting  process,  [electronic  resource]  :NPS-GSBPP-06- 
007. 

Rost,  J.  (2006).  Are  "best  practices"  requirements  documents  a  myth?  IEEE  Software, 
23(3),  104. 

SIGSOFT  2006  FSE-14  [electronic  resource]  :  Proceedings  of  the  14th  ACM  SIGSOFT 
International  Symposium  on  the  Foundations  of  Software  Engineering  : 

November  5-11,  2006,  Portland,  Oregon,  USA  (2006).  ISBN  97815934680. 

United  States,  General  Accounting  Office.  (1997).  Ballistic  missile  defense  (microform): 
current  status  of  Strategic  Target  System:  report  to  Congressional  requesters.  “B- 
259821”— P.l. 


58 


INITIAL  DISTRIBUTION  LIST 


1.  Defense  Technical  Information  Center 
Ft.  Belvoir,  Virginia 

2.  Dudley  Knox  Library 
Naval  Postgraduate  School 
Monterey,  California 


59 


